What is the standard way to bundle OSGi dependent libraries?

 

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

    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

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

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

    链接地址: http://www.djcxy.com/p/74748.html

    上一篇: 在glassfish 3.1中使用来自WAB的JPA

    下一篇: 绑定OSGi相关库的标准方式是什么？