Proprietary non-OSGi packages needed in OSGi application - can't redistribute

Question

I want to use proprietary, non-OSGi jars in an OSGi environment. For development, we just repackage/export it with the Maven bundle plugin [1]. Problem is, for legal reasons we won't be able to redistribute these packages to our customer, which kills both embedding and repackaging, which are (AFAIK) the only options (see [2]).

Before using OSGi, we had a section in our manual describing how to put these files in a library folder after acquiring them on ones own. Given OSGi rules for resolving classes, this obviously won't work anymore.

Am I correct to assume that the only way to solve this is a legal one, i.e. getting a redistribution license from the packages' vendor (which may be a beurocratic nightmare and impede timely delivery), or am I missing a technical solution?

[1] How can I share non-OSGi libraries between bundles in an OSGi container?

[2] Non-osgi library usage in an osgi application

Answer 1

I would simply add this JAR to the main Java application classpath, using its existing location in a library folder as you have already established. Then you can export the packages you need into OSGi using the org.osgi.framework.system.packages.extra property.

Answer 2

I have seen this requirement too in a commercial project. We ended up adding a special bundle, which on start-up downloaded the needed jars from the relevant sites and added them to our re-export bundles.

So

• we have a 3rd-party non-OSGi jar J.jar which we want to use
• we add an (almost) empty OSGi bundle with two files
  • a META-INF/MANIFEST.MF that re-exports all the relevant packages of J.jar
  • a simple text file - META-INF/DOWNLOADS - that specifies from where we can download J.jar
• we have a simple generic OSGi bundle (with a early start-up level) that goes through all installed bundles and checks if META-INF/DOWNLOADS exists. If it does, it downloads the specified jars if not already present.

When the re-export bundle is later started, it will look like we distributed the offending jar... and everybody are happy.

When we needed a new version of the jar, we just released a new version of our jar as we would normally do.. The main problems were how to handle any problems in the down-load process.

Answer 3

Perhaps OSGi Remote Services (distributed OSGi) could be an answer. You would host the OSGi environment that exposes the proprietary lib, and install the rest on the client's machine.