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

秦炜

2023-03-14

问题内容：

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

我希望嵌入的库之一是Jasper
Reports，但众所周知，它附带了许多支持jar文件的程序，我只需要一部分（已知的）jar文件，因此我打算自定义捆绑所有程序包我的依存库。

所以：

是否每个人都为正在使用的开放源代码库自定义自己的OSGi捆绑包，还是存在通用库的OSGi版本的主要来源？
另外，我还想过，将每个依赖包简单地将其依赖的jar嵌入到捆绑包本身中会容易得多。这可能吗？如果我选择将第3方foc库嵌入到一个包中，则假定我需要生成2个jar文件，其中一个不包含嵌入式库（用于通过标准classloader通过classpath加载库），以及一个包含以下内容的osgi版本：嵌入式库，因此我应该选择这样的捆绑包名称吗？<< myprojectname >>-<< subproject >>-osgi-.1.0.0.jar？
如果我无法嵌入开源库并选择自定义捆绑（通过bnd）开源库，我是否应该选择一个唯一的捆绑包名称以避免与可能的官方捆绑包冲突？例如<< myprojectname >>-<< 3rdpartylibname >>-<< 3rdpartylibversion >>。jar？
我的未启用OSGi的项目当前通过Service.providers（…）扫描我各种插件jar中的META-INF文件夹来扫描自定义插件。如果我使用OSGi，此机制是否仍然有效？

问题答案：

我宁愿不嵌入依赖罐（是有可能的）。它导致两个问题，

1）此代码不可重复使用。许多捆绑软件可能只是做相同的事情（嵌入同一个jar），而最终您安装了同一个jar多次。您可以争辩说您的包也可以导出嵌入式jar的接口，但这很难看，因为公开该代码不应该由您的包负责。它还使公开库的多个版本或同一版本的多个提供程序更加容易。

2）这是特定于Eclipse的-
嵌入式jar在开发环境中无法正确解析（仍然可以在运行时运行）。我的捆绑软件可能依赖于目标平台中的捆绑软件，并且无法解析嵌入式jar中的元素，必须将其导入工作空间才能正常工作。

我发现大多数开源jar都已经被Spring的好心人打包了。还有其他可用的存储库，但是不幸的是，我失去了与它们的链接。