What is the standard way to bundle OSGi dependent libraries?

6
votes

I have a project that references a number of open source libraries, some new, some not so new. That said, they are all stable and I wish to stick with my chosen versions until I have time to migrate to the newer versions (I tested hsqldb 2.0 yesterday and it contains many api changes).

One of the libraries I have wish to embed is Jasper Reports, but as you all surely know, it comes with a mountain of supporting jar files and I have only need a subset of the mountain (known) therefore I am planning to custom bundle all of my dependant libraries.

So:

  • Does everyone custom-make their own OSGi bundles for open-source libraries they are using or is there a master source of OSGi versions of common libraries?

  • Also, I was thinking that it would be far simpler for each of my bundles simply to embed their dependent jars within the bundle itself. Is this possible? If I choose to embed the 3rd party foc libraries within a bundle, I assume I will need to produce 2 jar files, one without the embedded libraries (for libraries to be loaded via the classpath via standard classloader), and one osgi version that includes the embedded libraryy, therefore should I choose a bundle name like this <<myprojectname>>-<<subproject>>-osgi-.1.0.0.jar ?

  • If I cannot embed the open source libraries and choose to custom bundle the open source libraries (via bnd), should I choose a unique bundle name to avoid conflict with a possible official bundle? e.g. <<myprojectname>>-<<3rdpartylibname>>-<<3rdpartylibversion>>.jar ?

  • My non-OSGi enabled project currently scans for custom plugins via scanning the META-INF folders in my various plugin jars via Service.providers(...). If I go OSGi, will this mechanism still work?

6
javapluginsosgipackaging

6 Answers

8
votes

I prefer to not embed the dependent jars (yes it is possible). It causes two problems,

1) There is no reuse of this code. Many bundles may simply do the same thing (embed the same jar) and you end up with the same jar installed many times. You can argue that your bundle can export the interfaces for the embedded jar as well, but this gets ugly since it should not be your bundles responsibility to expose that code. It also makes it easier to have multiple versions of the library exposed, or multiple providers of the same version.

2) This is Eclipse specific - The embedded jars don't resolve properly in the development environment (still works at runtime). My bundle may depend on a bundle in my target platform, and it will fail to resolve elements in the embedded jars, they have to be imported into the workspace to work.

I have found that most open source jars have already been kindly bundled by the nice folks at Spring. There are other repos available as well, but unfortunately I lost my links to them.

2
votes

Perhaps you are looking for something like Maven? Not sure how that would work with OSGi though. You can find a little info on Jasper Reports with Maven here: http://mvnrepository.com/artifact/jasperreports/jasperreports

2
votes

The Eclipse Orbit project has also made bundles from many commonly used third party jars.

http://www.eclipse.org/orbit/

1
votes

To be specific about the questions you asked.

Everyone doesn't make their own. See my previous answer for a link to the Eclipse packaging of third party libraries as bundles. If you can't find and already packaged version, you'll have to make your own.

It is better to wrap binary dependencies in their own bundle than to include the jar as a binary into your code bundle. Pick whatever bundle name you want, its the package imports and exports that matter. Namespacing the bundle name with your project name will make sure you don't hit collisions.

Getting access to the bundle storage area for scanning isn't impossible, but it tends to require OSGi runtime specific information on how/where the bundles get extracted. So it's possible, but not easy.

1
votes

spring has created osgi bundles of most of the open source libraries and i see jasper reports in there. check out their bundle repository @ http://www.springsource.com/repository/app/bundle

0
votes

we have been using Maven with OSGI, we declare the bundle dependencies in its pom.xml and you don't have to worry about them anymore.