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

Thanks all for all the clarifications. 

I might still import/export the javax.xml bundle, as it _is_ just a bunch 
of interfaces. But think I'll leave the rest the same. 

One clarification ... you said to use 
Export-Package: javax.xml.parsers; version="2.0"
Import-Package: javax.xml.parsers; version="[2.0, 2.0]"

but how is 

version="[2.0, 2.0]" different from 
version="2.0"

Is it that 2.0.0.qualifier would "fit" in [2.0, 2.0] but not in simply 
"2.0"? 


And, I didn't ask explicitly ... but should we in Orbit now use "uses" 
when we export a package? 
I think PDE can do this "automatically" now. Seems like I recall some 
issues or limitations with using 'uses' but do not recall. Should we 
encourage everyone to? 

Thanks,





From:
Thomas Watson/Austin/IBM@IBMUS
To:
Orbit Developer discussion <orbit-dev@xxxxxxxxxxx>
Date:
11/03/2008 10:13 AM
Subject:
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. 
> 
> 
> _______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev





Back to the top