我想在OSGi环境中使用专有的非OSGi jar。对于开发，我们只需使用Maven bundle plugin [1]重新打包/导出它。问题是，出于法律原因，我们无法将这些包重新分发给我们的客户，这会破坏嵌入和重新包装，这是（AFAIK）唯一的选择（参见[2]）。
在使用OSGi之前，我们在手册中有一节介绍如何在自己获取这些文件后将这些文件放入库文件夹中。鉴于解决类的OSGi规则，这显然不再适用。
我是否正确地认为解决这个问题的唯一方法是合法的，即从包裹的供应商那里获得再分配许可证（这可能是一个邪恶的噩梦，妨碍及时交付），或者我错过了技术解决方案？
[1] How can I share non-OSGi libraries between bundles in an OSGi container?
答案 0 :(得分：3)
我在商业项目中也看到了这个要求。我们最终添加了一个特殊的捆绑包，在启动时从相关站点下载了所需的罐子并将它们添加到我们的再出口捆绑包中。
所以
J.jar META-INF/MANIFEST.MF，可以重新导出J.jar META-INF/DOWNLOADS - 指明我们可以从哪里下载J.jar META-INF/DOWNLOADS是否存在。如果是，则下载指定的罐子（如果尚未存在）。稍后启动重新导出包时，看起来我们会分发有问题的jar ...并且每个人都很高兴。
当我们需要一个新版本的jar时，我们就像通常那样发布了一个新版本的jar ..主要问题是如何处理下载过程中的任何问题。
答案 1 :(得分：3)
我只是将这个JAR添加到主Java应用程序类路径中，使用它已经建立的库文件夹中的现有位置。然后，您可以使用org.osgi.framework.system.packages.extra属性将所需的包导出到OSGi中。
答案 2 :(得分：2)
也许OSGi远程服务(distributed OSGi)可能是一个答案。您将托管暴露专有lib的OSGi环境，并将其余部分安装在客户端的计算机上。
答案 3 :(得分：2)
这是非常哲学的。究竟是什么构成了数字内容的发行版？
（1）我们都同意，如果您的安装下载中包含有问题的jar，那就是重新分发。
（2）如果安装程序是一个瘦外壳，当它运行时会从互联网下载更多内容。如果它从你的服务器下载jar，我想大多数人会同意这与（1）基本相同，而且是重新分配。
（3）如果安装shell从所有者的服务器下载jar怎么办？假设它在没有最终用户知识的情况下自动化。
是否有人真的认为（3）与（2）非常不同，并且不重新分配？
我认为是，出于所有意图和目的。我们正在通过我们的程序有效地分发jar，如何在引擎盖下完成与再分发许可的精神无关。获得该程序的人随身携带jar，这是事实。
至少我们应该联系作者以确认他没问题。我们必须对自由软件给予应有的尊重，不要以违背作者意愿的方式使用它们。