OSGI bundles中Bundle类路径的预期用例是什么

我试图理解OSGI bundles中Bundle类路径的预期用例

这是我的理解，如果这是正确的，请帮助我理解

假设我正在创建一个OSGI捆绑包，它将部署在其他捆绑包的生态系统中。我正在处理的bundle需要一些其他bundle，但是它们没有在这个生态系统中加载/导出，并且我无法控制生态系统导出的内容。在这种情况下，我可以将这些包放在某个目录（比如“lib”）中，该目录将成为包的一部分。这些Bundle还应该从Bundle类路径引用，以便可以加载它们

• 这是Bundle类路径的正确用例吗
• 这些附加捆绑包是否也会加载到OSGI容器中，并且由它们导出的包是否可用于其他捆绑包

---

我想你可能有点不对劲
Bundle类路径是一个有序的、以逗号分隔的相对路径列表 要搜索类和资源的绑定JAR文件位置 请求
这意味着当某个bundle类需要另一个类时 同一个bundle，包含bundle的整个bundle类路径 被搜索以查找类
从
让我们考虑一个具体的例子。设想一个具有以下结构的包（JAR文件）：

src/a/A.class
src2/b/B.class
src3/c/C.class

如果希望

a.a

、

b.b

和

c.c

彼此可用，则必须将

src

、

src2

和

src3

定义为与bundle类路径相关的。这意味着您必须在清单文件中添加以下行：

Bundle-ClassPath: src,src2,src3

---

此标头最常见的用例是外部库的打包。假设您有一些库

foo.jar

，并且希望在包中使用它的类
你这样把罐子放进你的包里

/
  com/company/Activator.class
  foo.jar
  META-INF/MANIFEST.MF

在清单中，您现在可以使用

Bundle-ClassPath: foo.jar,.

记住在类路径中包含
，否则您将无法在包中找到类

---

当类位于

捆绑包类路径上时，您可以像使用任何其他类一样使用它们：在代码中使用它们，或导出它们。
捆绑包类路径
用于在捆绑包中包含依赖项，以便我们的捆绑包可以独立部署

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

只需在包中创建我自己的代码即可。bundle现在将有
Import-Package
语句来声明对Guava的依赖，任何想要将我的bundle部署到应用程序中的人也必须部署Guava

或者，我可以在我的包中包含一份番石榴的副本，并从我的
包类路径中引用它。无论谁部署了我的捆绑包，都可以部署我的捆绑包，并且不需要担心从哪里获得番石榴。事实上，我的包中存在Guava是一个实现细节，部署人员甚至不需要知道我正在使用它

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

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

因此，您应该小心不要过度使用
捆绑类路径
/
嵌入依赖项
。如果依赖项是（a）小且没有传递依赖关系，并且（b）您的包使用库作为内部实现细节，即它不是公共API的一部分，则只应考虑使用它。
更新

我忘了回答你关于出口的第二个问题。答案是否定的，您放在
包类路径上的任何“包”的导出都不会成为您自己的包的导出。事实上，我们放在
Bundle ClassPath
上的jar根本没有被当作Bundle处理，它们只是jar

您可以选择导出来自
捆绑包类路径上jar中的包，但必须在自己捆绑包的MANIFEST.MF中执行此操作。
当我在捆绑包类路径上放置jar（非osgi）时，我是否必须将它导入的类包含到我的导入包语句中？否：这些类的处理方式与包中的任何其他类完全相同。谢谢，那么我想一定是Maven包插件迫使我导入jarHm使用的类，不确定。尝试用生成的包的实际布局、清单和使用的maven语句更新您的问题。看起来maven包插件确实需要导入jar中的类，即使它不是OSGI jar。我会深入一点，更新我的问题。。。谢谢非常感谢！正是我想要的解释：-）谢谢！写得好。我想推荐一篇中档文章谢谢，这救了我，在我被困在一个问题上几个小时之后！