I am using jeromq-jms in an OSGi environment. In OSGi, a jar is called a bundle and OSGi can run many many bundles in parallel, kind of like an application server (in fact, applications servers are built on top of OSGi).
OSGi separates classpaths for all bundles by default which means that I cannot "see" any class from jeromq-jms. The solution is to import all the class files from the jar into my own jar so that we share the same classpath. Another solution, which is the preferred way in OSGi, is to add some headers to the MANIFEST.MF file in the jar. One of these headers is "Export-Package" which lists all Java packages this bundle should export to other bundles.
This PR simply adds the OSGi bundle maven plugin and exports all the packages. For other, non-OSGi consumers of the library, there is no difference, the resulting jar is a regular jar, just with added headers to the MANIFEST.MF. Non-OSGi environments just ignore those headers and load all the class files like normal.
mjeremym
commented
5 years ago
I am using jeromq-jms in an OSGi environment. In OSGi, a jar is called a bundle and OSGi can run many many bundles in parallel, kind of like an application server (in fact, applications servers are built on top of OSGi). OSGi separates classpaths for all bundles by default which means that I cannot "see" any class from jeromq-jms. The solution is to import all the class files from the jar into my own jar so that we share the same classpath. Another solution, which is the preferred way in OSGi, is to add some headers to the MANIFEST.MF file in the jar. One of these headers is "Export-Package" which lists all Java packages this bundle should export to other bundles.
This PR simply adds the OSGi bundle maven plugin and exports all the packages. For other, non-OSGi consumers of the library, there is no difference, the resulting jar is a regular jar, just with added headers to the MANIFEST.MF. Non-OSGi environments just ignore those headers and load all the class files like normal.