> You raise an interesting point on the subject of dependencies Java's
> "standard extensions." You say that dependencies on
> packages should be covered by Import-Package headers. However,
> since these packages are not deployed as OSGi bundles (in the JRE),
> presumably they are not exported with a version number by Export-
> Package headers.
Actually the non-java.* packages included in a JRE
are exported by the system.bundle (aka org.eclipse.osgi). The set
of packages exported (and their version numbers) is controlled by the "profile".
Equinox auto-detects the JRE on which you rae running and selects
a profile from a predefined set of profiles included in the bundle itself.
Users are free to create and run with their own profile.
> How would a bundle specify the version range
> the package that it imports? Does OSGi infer a version from
> Specification-Version headers in the JRE runtime JAR? Or should
> dependent bundle not specify a version in the Import-Package?
This is a bit of a challenge. The way Java is
delivered today it is not clear what the package version numbers should
be. For example, what is the version number of javax.management or
org.w3c.dom? We could blindly put on 1.5 or whatever the JRE version
number is but it is unclear if that is correct. So for now, you should
Import-Package and not specify a version number. The Equinox team
has been investigating how we can reliably get and use package version
numbering information but have not had any concrete answers. If someone
out there knows, please, tell us!
> I ask because I am wrestling with a problem of
dependencies on the
> org.w3c.dom API in trying to bundle-fy Apache Batik. Batik was
> originally distributed with Xerces 2.5, which includes some version
> of org.w3c.dom, but JREs since 1.2 also include org.w3c.dom. So,
> I'm supposing that I need to Import-Package this because it is a
> standard extension of the Java library, but this API has evolved
> over time so that the DOM in Xerces 2.5 is different from that which
> is defined by various levels of the JRE.
What would be great is if we could find out what versions
of these things are in the various JREs and then we could update the profiles
accordingly and you could import accordingly.