Handling Dependencies on OSGi Bundles

When we look in the Bnd Bundle Path, in the repository, or on jpm4j 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.