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?
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.