osgi - OSGI 包中 Bundle-Classpath 的预期用例是什么

Question

我试图了解 OSGI 包中 Bundle-Classpath 的预期用例。

这是我的理解，请帮助我理解这是否正确。

假设我正在创建一个 OSGI 包，它将部署在其他包的生态系统中。我正在处理的捆绑包需要一些其他捆绑包，但它们不会在这个生态系统中加载/导出，我无法控制生态系统导出的内容。在这种情况下，我可以将这些包放在某个目录(比如“lib”)中，该目录将成为我的包的一部分。这些包也应该从 Bundle-Classpath 中引用，以便可以加载它们。

这是 Bundle-Classpath 的正确用例吗？

这些额外的包是否也会加载到 OSGI 容器中，并且由它们导出的包是否可用于其他包？

Answer 1

Bundle-ClassPath旨在将依赖项包含在我们的包中，以便我们的包可以独立部署。

让我们举个例子。假设我的包中的代码使用了一个库，例如谷歌 Guava 。我有两种打包我的捆绑包的选择:

只需创建我的包，其中只有我自己的代码。该捆绑包现在将具有 Import-Package声明依赖于 Guava 的语句，任何想要将我的包部署到他的应用程序中的人也必须部署 Guava。

或者，我可以在我的包中包含 Guava 的副本，并从我的 Bundle-ClassPath 中引用它。 .部署我的包的人可以只部署我的包，而无需担心从哪里获取 Guava。事实上，我的 bundle 中 Guava 的存在是一个实现细节，部署者甚至不需要知道我正在使用它。

这两个选项之间的选择是一种权衡。选项 2 的优点是我的包更容易部署，因为它是独立的——它需要的一切都在其中。另一方面，我的包比它需要的要大得多，如果许多其他包也嵌入了他们自己的 Guava 副本，这可能会成为一个问题。

选项 2 的一个更严重的问题是库的所有依赖项现在都变为 。我的 依赖关系也是如此。实际上，Guava 是一个罕见的没有自身依赖的 Java 库示例……但许多其他 Java 库拖入了一个巨大的传递依赖树。如果您将这种方法与 Hibernate 一起使用，那么您自己的 bundle 也将具有那么大的依赖集。这变得非常难看，很快。

所以，你应该小心不要过度使用 Bundle-ClassPath/ Embed-Dependency .如果依赖项很小，并且没有传递依赖项，并且 (b) 您的包使用该库作为内部实现细节，即它不是您的公共(public) API 的一部分，您应该只考虑使用它。

更新

我忘了回答你关于导出的第二个问题。答案是否定的，您放在 Bundle-ClassPath 上的任何“捆绑”的导出不会成为您自己的捆绑包的导出。事实上，我们放在 Bundle-ClassPath 上的 JAR根本不被视为捆绑包，它们只是 JAR。

您可以选择导出来自您的 Bundle-ClassPath 上的 JAR 中的包。但您必须在您自己的捆绑包的 MANIFEST.MF 中执行此操作。