Handling Dependencies on OSGi Bundles
When we look in the Bnd Bundle Path
, in the repository we can see that org.jaxen
is an OSGi bundle. So in that case we could allow the import of its packages instead of wrapping it inside our bundle.
When to refer and when to include. In general, dependencies are evil. Adding a dependency to save a few bytes is usually not worth it. When systems become complex it quickly becomes really problematic to ensure that no two dependencies conflict on their versions. Though OSGi can handle multiple versions in a JVM, the consequences are still not anything to be desired for a reliable application.
In a perfect world the only dependencies are therefore APIs to an abstraction of a shared functionality. For example, you cannot include an Event Admin implementation because the whole purpose of that service is that it is shared between all bundles. However, you can include an ASM bytecode manipulation library since it is perfectly okay that different bundles use different versions of this library as long as they do not interchange types of it.
Anyway. To make jaxen
bundle an external dependency we need to add the org.jaxen
packages to the -conditionalpackage
instruction with a ‘!’ so they will not be included in our bundle.
-conditionalpackage: \
!javax.*, \
!org.xml.*, \
!org.w3c.*, \
!org.ietf.jgss, \
!org.omg.*, \
!org.jaxen.*, \
*
We could of course remove it from our -buildpath
so bnd could not find it. That is, however, a bad idea. By leaving it on the -buildpath
we allow bnd to learn the versions of the packages so it can properly version the packages in our target bundle. If we look at our imports now in the Contents
tab:
We can see that the org.jaxen package is now imported with a real version range.
One down, some more to go. What if we want to optionally depend on something? Stay tuned.
Prev Next