OSGi应用程序中需要专有的非OSGi包 - 无法重新分配

我想在OSGi环境中使用专有的非OSGi jar包。对于开发，我们只需使用Maven bundle插件重新打包/导出它[1]。问题是，出于法律方面的原因，我们无法将这些软件包重新分发给我们的客户，这会杀死嵌入和重新打包，这是（AFAIK）唯一的选择（参见[2]）。OSGi应用程序中需要专有的非OSGi包 - 无法重新分配

在使用OSGi之前，我们在手册中有一节介绍了如何在自己获取这些文件后将这些文件放在库文件夹中。鉴于OSGi规则解决类，这显然不会工作了。

我是否正确地认为解决这个问题的唯一方法是合法的，即从软件包的供应商那里获得再分配许可证（这可能是一种贵族式的噩梦并阻碍及时交付），还是我错过了一项技术解？

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

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

来源

2011-08-01 Christoph

我只是简单地将这个JAR添加到主Java应用程序类路径中，使用它已经建立的库文件夹中的现有位置。然后，您可以使用org.osgi.framework.system.packages.extra属性将所需的软件包导出到OSGi中。

来源

2011-08-01 14:41:38

非常好，谢谢！我错过了这个属性。 – Christoph

也许OSGi的远程服务(distributed OSGi)可能是一个答案。您将承载公开专有库的OSGi环境，并将剩余的安装在客户机上。

来源

2011-08-01 12:11:57 RaduK

我在一个商业项目中也看到了这个要求。我们最终添加了一个特殊的软件包，它在启动时从相关站点下载了所需的jar并将它们添加到我们的再出口软件包中。

所以

我们有一个第三方的非OSGi的罐子J.jar我们想用
我们添加的（几乎）空OSGi包有两个文件
- 一个META-INF/MANIFEST.MF是重新 - 出口所有相关包J.jar
- 一个简单的文本文件 - META-INF/DOWNLOADS - 指定我们可以从哪里下载J.jar
我们有一个简单的通用OSGi包（具有较早的启动级别），通过所有安装的包并检查是否存在META-INF/DOWNLOADS。如果确实如此，则它下载指定的罐子（如果尚未存在的话）。

当重新导出包稍后启动时，看起来就像我们发布了冒犯的jar ......每个人都很开心。

当我们需要新版本的jar时，我们刚刚发布了我们的jar的新版本，正如我们通常所做的那样。主要问题是如何处理下载过程中的任何问题。

来源

2011-08-01 13:28:26

这看起来是可行的，我喜欢下载内容的（潜在的）横切关注的事实不是由需要下载的软件包实现的。虽然这可能不是我解决当前问题的方法，但我会记住这个OSGI特定的关注分离模式，因为它在许多情况下可能很有用。 – Christoph

这是非常哲学的。数字内容的确切构成分配？（1）我们都同意，如果有问题的jar包含在您的安装下载中，它是一个重新分发。（2）如果安装程序是一个精简的外壳，当它运行时，它会从互联网下载更多的内容。如果它从你的服务器下载jar，我认为大多数人会同意这与（1）基本相同，并且是重新分发。

（3）如果安装shell从所有者服务器下载jar，该怎么办？假设它没有最终用户的知识就自动化了。

难道有人真的认为（3）与（2）有很大不同，并且它是而不是的再分配？

我认为它是，为所有意图和目的。我们正在有效地发布我们的程序，这是如何做到底的，与再分配许可的精神无关。无论谁获得该计划都会得到这个罐子，这是一个事实。

至少我们应该联系作者来验证他是否可以使用它。我们必须对免费软件给予应有的尊重，不要以违背作者意愿的方式使用它们。

来源

2011-08-01 15:24:25 irreputable

OSGi应用程序中需要专有的非OSGi包 - 无法重新分配

回答

相关问题