捆绑OSGi依赖库的标准方法是什么？

Question

我有一个项目引用了许多开源库,一些是新的,一些不是那么新.也就是说,它们都是稳定的,我希望坚持我选择的版本,直到我有时间迁移到更新的版本(我昨天测试了hsqldb 2.0并且它包含许多api更改).

我希望嵌入的其中一个库是Jasper Reports,但是你们肯定知道,它带有一大堆支持jar文件,我只需要一个山的子集(已知)因此我打算自定义捆绑所有我的依赖库.

所以:

• 是否每个人都为他们正在使用的开源库定制自己的OSGi包,或者是OSGi版本的公共库的主要来源？

• 此外,我认为我的每个捆绑包只是简单地将其依赖的jar嵌入捆绑包本身就会简单得多.这可能吗？如果我选择在一个包中嵌入第三方foc库,我假设我需要生成2个jar文件,一个没有嵌入式库(用于通过类路径通过标准类加载器加载的库),以及一个包含的osgi版本嵌入式库,因此我应该选择像这样的<< myprojectname >> - << subproject >> - osgi-.1.0.0.jar？

• 如果我无法嵌入开源库并选择自定义捆绑开源库(通过bnd),我应该选择一个唯一的捆绑名称以避免与可能的官方捆绑包发生冲突吗？例如<< myprojectname >> - << 3rdpartylibname >> - << 3rdpartylibversion >> .jar？

• 我的非OSGi启用项目当前通过Service.providers(...)扫描各种插件罐中的META-INF文件夹来扫描自定义插件.如果我去OSGi,这个机制还能运作吗？

Answer 1

我宁愿不嵌入依赖的罐子(是的,这是可能的).它会导致两个问题,

1)没有重用此代码.许多捆绑包可能只是做同样的事情(嵌入相同的jar),你最终安装了多次相同的jar.您可以争辩说,您的软件包也可以导出嵌入式jar的接口,但这很难看,因为它不应该是您的捆绑责任来公开该代码.它还使得公开多个版本的库或同一版本的多个提供者更容易.

2)这是Eclipse特定的 - 嵌入式jar在开发环境中无法正确解析(仍然在运行时工作).我的捆绑包可能依赖于我的目标平台中的捆绑包,并且它将无法解析嵌入式jar中的元素,必须将它们导入工作区才能工作.

我发现大多数开源jar都已经被Spring的好朋友们亲切地捆绑了.还有其他的回购,但不幸的是我丢失了他们的链接.