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

Question

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

我希望嵌入的库之一是 Jasper Reports，但正如你们肯定知道的那样，它带有大量的支持 jar 文件，而我只需要其中的一个子集(已知)，因此我打算自定义捆绑我所有的依赖库。

所以:

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

• 另外，我在想，如果我的每个包都简单地将它们的依赖 jar 嵌入到包本身中，会简单得多。这可能吗？如果我选择将第 3 方 foc 库嵌入到一个包中，我假设我将需要生成 2 个 jar 文件，一个没有嵌入式库(用于通过标准类加载器通过类路径加载的库)，以及一个包含的 osgi 版本嵌入式库，因此我应该选择这样的包名称 < >-< >-osgi-.1.0.0.jar 吗？

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

• 我的未启用 OSGi 的项目目前通过 Service.providers(...) 扫描我的各种插件 jar 中的 META-INF 文件夹来扫描自定义插件。如果我使用 OSGi，这个机制是否仍然有效？

Answer 1

我宁愿不嵌入相关的 jar(是的，这是可能的)。它会导致两个问题，

1) 没有重复使用此代码。许多 bundle 可能只是做同样的事情(嵌入相同的 jar)并且你最终安装了相同的 jar 多次。您可以争辩说您的包也可以导出嵌入式 jar 的接口(interface)，但这变得很难看，因为公开该代码不应该是您的包的责任。它还可以更轻松地公开多个版本的库，或同一版本的多个提供者。

2) 这是 Eclipse 特有的——嵌入式 jar 在开发环境中无法正确解析(在运行时仍然有效)。我的 bundle 可能依赖于目标平台中的 bundle，它无法解析嵌入式 jar 中的元素，它们必须导入工作区才能工作。

我发现大部分开源jar都已经被友善bundled by the nice folks at Spring .还有其他可用的存储库，但不幸的是我丢失了指向它们的链接。