Before we continue we must raise the question: “Do you really need that dependency?” In the software world we have an abundance of open source projects that provide us with almost any desired functionality today. The fact that a JAR is not OSGified is actually a warning sign because adding the minimal OSGi headers requires very little work. Almost all successful open source libraries nowadays include OSGi support out of the box.
The second warning sign you should be aware off is the sheer number of dependencies. If your target JAR has > ±10 external dependencies then you should seriously consider skipping it if it is anyway possible. Though it is okay for applications to have this many dependencies, it is extremely painful to have a component with such a large fan out. Not only are such dependencies tedious, over time they tend to become an unsolvable problem because the dependencies of this component start to constraint your own dependencies.
A good component is highly cohesive and has minimal (preferably API based) dependencies.
The third thing to consider is that OSGi is not about class loading; it is about services. The highest value in OSGi lies in its service model. With the service model it is possible to keep virtually all implementation details hidden inside the bundle. Unfortunately, writing service oriented bundles is an architectural aspect; it is hard to add this in general to a JAR that is written to reside on the class path and thrive on class loader hacks.
And we hardly dare to raise the issue, did someone already provide the wrapped bundle for you?
One way to find out is to use JPM4J. You can search for keywords and limit them to OSGi bundles. For example, search on:
jdom osgi:* and you see all bundles that are at least related to JDOM but that are OSGi ready. JPM4J has many more search options.
There are some resources on the net that provide wrapped bundles:
Ok, you’re still here … So I guess the need is dire. Let’s see how we can wrap an existing bundle.