我有一个包含大量 jar 文件的目录。更具体地说:Apache Spark。现在我想使用 Spark 库编写一个 Java/osgi 程序。最好的方法是什么？
一种方法是将整个 200MB 捆绑到一个 osgi 包中。结果将是一个巨大的插件，其中包含与服务器上相同的 jar 文件，并且在最坏的情况下与服务器的 Spark 版本不兼容。
另一个选择是将所有 200MB 的 jar 文件添加到项目的 lib 文件夹中，并将它们视为嵌入式库。与上面相同的问题。
唯一的其他选择是在运行时破解类加载器，将 Spark 的 jar 目录添加到类路径中。这也不好。
但坦率地说，在我看来，这个用例超出了 osgi 应该做的事情。 osgi 用于控制依赖关系，包括版本，我要求使用已经安装的版本。矛盾不是吗？
你有什么建议吗？我忽略了什么？
提前致谢!
最佳答案
OSGi 是关于软件工程的。关于验证您的编译时依赖项是否与兼容的运行时依赖项相匹配。当您遵循(简单)规则时，您最终会得到一个比没有 OSGi 时更可靠的系统，因为没有任何内容是“假设的”，就像在许多非 OSGi 项目中一样。
不幸的是，这意味着您需要正确获取元数据。尽管现在有大量代码拥有 OSGi 元数据，但人们自然倾向于走捷径。在那一刻，你将面临两全其美的情况。你没有得到很多好处，但你仍然付出代价。恕我直言，OSGi 是一种“全方位”技术，选择某些部分几乎没有什么好处。
如果我遇到你的问题，我会分析我的代码需要 Spark 提供什么，看看是否可以将其转化为许多干净、内聚且解耦的服务 API。我会根据这些 API 编写代码。在 OSGi 运行时中，我将使用我自己的依赖项。我将从框架外部注册 Spark 服务实现，以便 Spark 类空间和 OSGi 类空间是分开的。然而，这并不是一件小事，因为许多 API 往往会泄漏实现细节和实现依赖性。
根据我的经验，尝试移植一个不是为 OSGi 设计且具有 200 Mb 依赖项的开源项目是一项主要任务。这与尝试为一个并非从头开始设计的程序添加安全性以考虑安全性非常相似。
关于java - osgi NoClassDefFoundError - jar 目录，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/56865183/