Tip: Third Party Bundles

A common question I come across when working with people using OSGi-based systems is how to deal with third party dependencies… especially third party dependencies that aren’t in bundle form. There are generally two ways to deal with third party dependencies… you can either reuse a bundle that already exists in some repository… or you can roll your own bundle. For most people, I recommend that they first attempt to reuse a bundle if it exists already, than if not, build your own. Let’s use a real world example like the Apache Commons Httpclient library.

Finding a bundle

The first place you want to look is on the third party website. In this case, I couldn’t find a bundle version of the library so I will have to look elsewhere. This will actually be very common as there aren’t many libraries out there that I know that come in bundle form already. The next step would be to check other repositories to see if someone has done the work already to bundle the third party library you’re interested in. The two repositories I commonly check is the Eclipse Orbit repository and the Spring Bundle Repository. Looking at the Orbit repository, I see that the version of Httpclient I need is there so my search is over. I find that the most commonly used libraries out there are available in Orbit or the Spring Bundle repositories.

Rolling your own

So what happens if you can’t find the bundle you need? Well, you can pretty easily roll your own bundlized version of the library using some tools. One way to do it is to use PDE‘s ‘New Plug-in Project from existing JAR archives’ wizard:

This allows you to simply select the libraries you’re interested into converting into bundles and it will magically create the bundle for you. That’s it! The only downside to this is that you can’t run this in a headless fashion if you need to. If you need to do this process in a headless fashion, you can use another popular bundle conversion tool called BND. BND has command line options if you need to run this bundle conversion process headless. Furthermore, it even has Ant tasks that you can hook into if you wish to run this process as part of your build. It just depends on your needs on which tool you choose.

Well that’s it… this process works pretty well for me and the people I have worked with. If people have any other tips for dealing with third party dependencies, feel free to comment!

3 Responses to “Tip: Third Party Bundles”

  1. Glenn says:

    I’ve managed to migrate most ./lib/ jars into bundles, but there are a few that are just problematic. It seems to have problems with classloading. Commons BeanUtils & DBCP both won’t operate as bundles. Does it have to do with the commons logging problems?

  2. zx says:

    @Glenn, where are you getting commons beanutils and DBCP?

    I don’t recommend rolling your own for those as those are available from Orbit and SpringSource. For common libraries, the preferred route is getting it from a public source. Any other information you can give me to help you? It’s hard to do this without logs ;)

  3. Lars Vogel says:

    Hi, little add-on for how to use the third party libraries which you got in bundle form:


3 responses so far

Written by . Published in Categories: EclipseSource News

Looking for a job?

Karlsruhe / Remote
Karlsruhe / Victoria / Remote
Karlsruhe / Victoria / Remote