• Guide Tutorials Examples Services App notes Links FAQ Forum
  • Guide
    Tutorials
    Example Projects
    Documentation
    Service Catalog
    OSGi Specifications
    App Notes
    Where to Find Stuff
    Videos
    Known Issues
    Frequently Asked Questions
  • Prev Next

    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.

    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:

    Importing jaxen

    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
    • Copyright © 2021 OSGi™ Alliance.