Guide Tutorials Examples Services App notes Links FAQ Forum
This website and its associated repositories, are deprecated and no longer supported by the OSGi Alliance. Please visit https://enroute.osgi.org for the latest supported version of OSGi enRoute.
This enRoute v2 archive site is kept for those who do not intend to use the latest version of OSGi enRoute. If you are new to OSGi enRoute, then please start with the latest OSGi enRoute.
So far we’ve ignored the nasty concept of versions. We were forced to export a lot of packages that are not semanticaly versioned. By default, bnd gives these packages the version of their bundle, which is an awful defaultbut we don’t know any better. In our example, this looks like:
Export-Package
org.dom4j {version=1.6.1, imported-as=\[1.6,2)}
org.dom4j.bean {version=1.6.1}
org.dom4j.datatype {version=1.6.1}
org.dom4j.dtd {version=1.6.1, imported-as=\[1.6,2)}
org.dom4j.io {version=1.6.1, imported-as=\[1.6,2)}
org.dom4j.rule {version=1.6.1, imported-as=\[1.6,2)}
org.dom4j.rule.pattern {version=1.6.1, imported-as=\[1.6,2)}
org.dom4j.swing {version=1.6.1}
org.dom4j.tree {version=1.6.1, imported-as=\[1.6,2)}
org.dom4j.util {version=1.6.1, imported-as=\[1.6,2)}
org.dom4j.xpath {version=1.6.1, imported-as=\[1.6,2)}
org.dom4j.xpp {version=1.6.1, imported-as=\[1.6,2)}
org.gjt.xpp {version=2.1.10, imported-as=\[2.1,3)}
org.relaxng.datatype {version=1.0.0, imported-as=\[1.0,2)}
Sadly, there is no good solution. It is one of those things where only the author can provide good semantic versions, anything someone else does will back fire one day. And this does makes sense because semantic versioning is basically a promise from the author to signal the compatibility of future changes in the version number.
Note that version ranges cannot be added for JRE packages, e.g.
javax.swing or org.xml.sax because the Java specifications do not
define the version of any of these packages, and therefore the OSGi
framework exports them all as version 0.0.0. As an alternative, add a
Bundle-RequiredExecutionEnvironment header to indicate the basic Java
level required by the bundle:
Bundle-RequiredExecutionEnvironment: J2SE-1.8
Other possible values include JavaSE-1.6, OSGi/Minimum-1.0, etc.
If we wanted to control the versions in more detail we could decorate the Export-Package header. In general you then want to use macros to specify these versions so you won’t have to repeat yourself.
version-dom4j = 1.6.1
version-relaxng = 1.0.0
version-gjt = 2.1.10
Export-Package: \
org.dom4j.*;version=${version-dom4j}, \
org.relaxng.datatype;version=${version-relaxng}, \
org.gjt.xpp;version=${version-gjt}
This gives us an export list of:
Export-Package
org.dom4j {version=1.6.1, imported-as=[1.6,2)}
org.dom4j.bean {version=1.6.1}
org.dom4j.datatype {version=1.6.1}
org.dom4j.dtd {version=1.6.1, imported-as=[1.6,2)}
org.dom4j.io {version=1.6.1, imported-as=[1.6,2)}
org.dom4j.rule {version=1.6.1, imported-as=[1.6,2)}
org.dom4j.rule.pattern {version=1.6.1, imported-as=[1.6,2)}
org.dom4j.swing {version=1.6.1}
org.dom4j.tree {version=1.6.1, imported-as=[1.6,2)}
org.dom4j.util {version=1.6.1, imported-as=[1.6,2)}
org.dom4j.xpath {version=1.6.1, imported-as=[1.6,2)}
org.dom4j.xpp {version=1.6.1, imported-as=[1.6,2)}
org.gjt.xpp {version=2.1.10, imported-as=[2.1,3)}
org.relaxng.datatype {version=1.0.0, imported-as=[1.0,2)}
Whatever you do, the fact that the packages are not versioned by the author makes it a losing game. So this probably works when you use this bundle yourself but it is dangerous to publish it to the world or place it on maven central.