Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [orbit-dev] Question on details of export, import, and requires

Hi David,

See comments below.

Tom



orbit-dev-bounces@xxxxxxxxxxx wrote on 11/03/2008 01:18:19 AM:

> David M Williams

>
> I've been thinking of improving the constraints specified by our xerces,
> and javax.xml bundles, etc. and have a few questions.
>
> 1. If "import-packages" is specified, is there any reason to also specify
> "require-bundle"? I'd suspect not, but would it be wrong to? In
> particular, I'm thinking of the "Require-Bundle: system.bundle" technique
> we've used. We do that so our bundle would "override" anything found from
> the java VM, so am wondering it there's an equivalent concept with
> Import-package, or if it would not be required in that case.


The use of "Require-Bundle: system.bundle" by some orbit bundles is always hard to explain.  In the cases I have analyzed the bundles do not want to override the packages from the java VM.  Instead they want
to provide their content of the package if the package is not available from the VM.  In other cases they want to add a few "missing" classes from the package provided by the VM.

This all became complicated with the introduction of the OSGi R4 runtime which does not give all access to the boot class path for free.  Bundles must declare their constraints to access non java.* packages from the boot classpath.  In Eclipse 3.0 - 3.2 all bundles got the content of the boot classpath for free because we delegated to boot first.  So bundles which exported packages which also were available from the VM boot classpath were effectively exporting a split package.  In 3.3 the Equinox framework was changed to be correct WRT OSGi boot delegation.  See http://wiki.eclipse.org/Equinox_Boot_Delegation.  In order to get the same behavior as before these types of bundles needed to require the system.bundle so that they would delegate to the VM for the packages available from the VM first before their own content for the package.

In short, there is no equivalent Import-Package statement to replace the Require-Bundle: system.bundle statement.

>
> 2. How to specify ranges? When we 'require bundles' we always specify a
> range, such as [1.3.4, 2.0.0). Is that still important when using import
> package? I'd assume so ... but, sure seems tedious. :) What about on
> "uses" ... any ranges to specify there?


Yes you can and should use version ranges for the packages you depend on.  It is tedious, but hopefully your list of packages dependencies is not large.  PDE does have some tooling to help you determine the package dependencies.

>
> 3. I've heard, as I'm sure we all have, we should import what we export.
> See
> http://www.osgi.org/blog/2007/04/importance-of-exporting-nd-importing.html
> While counter-intuitive, I can see the rationale to be a "good osgi
> citizen" ... but, what to do about ranges then? We are obviously only
> exporting exactly one version ... I assume we'd import only that exact
> same version ... even if ranges specified on other imports?
>


You should import with a strict version range, for example:

Export-Package: javax.xml.parsers; version="2.0"
Import-Package: javax.xml.parsers; version="[2.0, 2.0]"

This allows another bundle's export of javax.xml.parsers to substitute your version of the export.  See https://bugs.eclipse.org/bugs/show_bug.cgi?id=217724.  You should not do this when running on an Eclipse release less than 3.4.1.  Bug 217724 was released for the 3.4.0 release, but we had a potential for stack overflow which was fixed in 3.4.1. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=235958

I'm not convinced this is something we want to do for our library bundles in orbit though.  Clients using require-bundle on the orbit bundles expect to get the package from the orbit bundle.  Substitutable exports no longer make that guarantee.  Substitutable exports make the most sense when the package is pure API with little to no implementation.

Tom.

> Thanks for any insights.
>
>
>


Back to the top