Saturday, July 25, 2009

Installing OSGi bundles with dependencies

One of my favorite features of OSGi is you can write jars/bundles that provide code and/or services to other jar/bundles. However, one of my least favorite features of OSGi is how you can't just install a single jar, as most likely, that bundle will require packages and services from other bundles in order to work. Passing a list of bundles with instructions to install them in a certain order sucks.

To help solve this deficiency, there is the OSGi Bundle Repository (OBR), which is a bit like Maven 2's dependency management in that when you install a bundle using it, OBR can look at external repositories to find any required dependencies and install them as well. Unfortunately, a) there is barely any documentation or code samples out there on integrating OBR into your OSGI application and b) having an OSGi app go out to the internet to download other bundles at runtime just plain scares me; take Maven's penchant for downloading the internet and put that "feature" into your production application... *shudder*.

The solution I came up with uses the dependency resolution aspect of OBR but without needing any network access. Instead of installing a bundle directly, you install an ".obr" file, which is a zip file with the following layout:

When installed, the installer looks at the obr.xml and determines if the main bundle can be installed as is. If there are any missing dependencies, it takes them from the "dependencies" directory and installs as necessary. Therefore, only the necessary bundles are installed yet OBR doesn't go out to the network, and, bottom line, you can again distribute and install one file.

The obr.xml file is the standard OBR descriptor file that describes the main bundle and all its dependencies. The dependency bundles are packaged in the .obr zip only to be used if needed during installation. For example, if user A installs the .obr file on their osgi system that already contains dep-bundle.jar, then the installation process will only install dep-bundle2.jar. If user B has neither, then the installation process installs both dependency bundles.

There are other options I found (PAR, DeploymentAdmin) for grouping bundles, however, they tend to exist as a way to define multiple bundles as a single, possibly indivisible, unit, but in our case, dependencies are meant to be shared between bundles of different origins. Did I miss anything or is this the best option for achieving my goals?


  1. Nice solution. I am in a process of exploreing OSGI myself
    There are many aspects which OSGI has not mentioned in its specifications like though bundles can be restarted from inside the framework but there is no way to read from properties file [ or any configuration file for that matter]. At the moment any propertie file created for OSGI is added into the buddle [jar file ] thus making it real tough for the users to modify its contents.

    Some of my post on OSGI link mentioned below..


  2. Don

    Check out Nimble & POSH.

    Nimble is a powerful generic graph dependency resolver - built for OSGi, but now understands a number of artifact types.

    Some generic background can be found here - and slides and download (see POSH
    slides) here.

    Nimble -

    POSH -



  3. Yep, this is a standard use case for OBR. This is why I always pushed for OBR to be a server-less solution, so people could easily set up their own repositories for their own purposes, with no requirement for network connectivity.

    -> richard

  4. Nice blog. To the point.

  5. Don, the SpringSource dm Server also works in a similar way - you have an on-disk "repository" (just a file system), and when you deploy a given bundle to the server, if it has unsatisfied dependencies, bundles are automatically provisioned from the repository in order to satisfy them so that the install can succeed.

  6. Eclipse P2 I think is a nice solution for these dependency issues. It has bundle pooling functionality within P2 that would be similar to your solution (if the bundle pool was a single file).

  7. Java Platform, Enterprise Edition (Java EE) java software company is the industry-standard platform for building enterprise-class applications coded in the Java programming language. java software outsourcing Based on the solid foundation of Java Platform, Standard Edition (Java SE), Java EE adds libraries and system services that support the scalability, accessibility, security, java developers integrity, and other requirements of enterprise-class applications.

    1. Good point of view and nice visiting this site ..your blogs always explain a brilliant topic so that we can gain a good knowledge here.Thanks for this useful post.
      web designing company

  8. Oakley is constantly developing new technology in order to provide athletes of all sports with a way to protect their vision in a stylish way. This company, named after one of Jannard's dogs, has ray ban outlet come a long way since its humble beginnings and it has proved it will be a brand in sports for years to come.Oakley sunglasses have been known for their distinct quality and intricate designs, which have gained the name a good reputation for quite some time now. However, quality pieces often come with costly price tags, which is actually reasonable for Oakley sunglasses. And due to this, the rise of fake Oakley sunglasses has been very much noticeable in the market.