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

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开发者_如何学C.

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

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.

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.

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.

This is quite philosophical. Just what exactly constitutes a distribution of digital content?

(1) We all agree that if the jar in question is included in your installation download, it's a redistribution.

(2) What if the installation program is a thin shell, when it runs, it downloads more stuff from internet. If it downloads the jar from your server, I think most people would agree that this is essentially the same as (1), and it is a redistribution.

(3) What if the installation shell downloads the jar from the owner's server? Suppose it is automated without end user knowledge.

Could anybody really argue that (3) is very different from (2), and it is not a redistribution?

I think it is, for all intents and purposes. We are effectively distributing the jar with our program, how that is done under the hood is not relevant with regard to the spirit of the redistribution license. Whoever gets the program gets the jar along with it, that is a fact.

At least we should contact the author to verify he is ok with it. We must pay due respect to free softwares, do not use them in a way that's against the wills of the authors.