OSGi bundle imports packages from non-bundle jars: create bundles for them?

Question

I am new to OSGi, and am using Equinox. I have done several searches and can find no answer to this. The discussion at OSGI - handling 3rd party JARs required by a bundle helps somewhat, but does not fully answer my question.

I have obtained a jar file, rabbitmq-client.jar, that is already packaged as an OSGi bundle (with Bundle-Name and other such properties in its MANIFEST.MF), that I would like to install as a bundle. This jar imports packages org.apache.commons.io and org.apache.commons.io.input from commons-io-1.2.jar. The RabbitMQ client 2.7.1 distribution also includes commons-cli-1.1.jar, so I presume that it is required as well.

I examined the manifests of these commons jars and found that they do not appear to be packaged as bundles. That is, their manifests have none of the standard bundle properties.

My specific question is: if I install rabbitmq-client.jar as a bundle, what is the proper way to get access to the packages that it needs to import from the commons jars? There are only three alternatives that I can think of, without rebuilding rabbitmq-client.jar.

1. The packages from the commons jars are already included in the Equinox global classpath, and rabbitmq-client.jar will get them automatically from there.
2. I must make another bundle with the two commons jars, export the needed packages, and install that bundle in Equinox.
3. I must put these two commons jars in the global classpath when I start Equinox, and they will be available to rabbitmq-client.jar from there.

I have read that one normally does not use the global classpath in an OSGi container. I am not clear on whether items from the global classpath are even available when building individual bundle classpaths. However, I note that rabbitmq-client.jar also imports other packages such as javax.net, which I presume come from the global classpath. Or is there some other bundle that exports them?

Thanks for any assistance!

Answer 1

Solution (2) is the correct way. (1) and (3) will not work because, as you seem to understand already, there is no such thing as a global classpath in OSGi.

Each bundle imports all the packages that it needs, and those packages must be exported by another bundle. There is an exception to this, which is all the classes under the java.* namespace... i.e. there is no need to import java.lang, java.util etc.

Packages such as javax.net do come from the JRE but they are still not on a "global classpath". There is a special bundle called the System Bundle, which represents the OSGi Framework itself within OSGi. That bundle exports a bunch of packages that come from the JRE such as javax.net, javax.swing, org.w3c.dom, etc.

Answer 2

I'd also add to what Neil has said that for popular bundles, like commons-io, there's usually no need for option (2), since someone else has already done it. There is a SpringSource repository with many converted bundles. For commons-io you can do even better, since version 1.4 of the 'official' jar on maven central is already a bundle.