Maven提供了广泛的依赖模型。一个项目有一个pom，该pom指定其对其他pom的依赖关系。这是传递性的，因此有一个依赖项可能会下载一半的互联网。在Maven中，您可以指定需要在编译类路径或运行时类路径中使用依赖项。
在OSGi中，应创建一个可在不同环境中使用的bundle。因此，bundle是一个显式声明其依赖关系的JAR。就像Maven一样，您可以让一个bundle依赖另一个bundle（Require-Bundle）。但是，要求另一个bundle实际上是相当脆弱的。
它倾向于创建大型依赖图表
您很容易陷入需要在不同版本中使用相同工件的情况
您需要太多，因为您通常只需要另一个bundle的一部分
通常您希望使用不同的实现
因此，OSGi具有基于
功能的本地依赖模型。包出口是一个能力。在OSGi中，Bundle A不依赖于Bundle B，而是依赖于package b。（并且包应该表示合同/ API。）导出包b的任何bundle都将满足bundle A。这种模型具有许多优点，最大的优点是它不是传递性的。这在部署时提供了极大的灵活性。
在OSGi中，关键目标是最小化依赖项，并仅依赖于定义良好的API，而不是实现，因此bundle易于在许多不同的上下文中使用。
那么如何在Maven中构建它？
一般来说，可以让bnd分析您的代码。然后，它将创建一个清单，精确地表达了您的bundle依赖于哪些包。
但是，开源代码的结构方式很可能不仅依赖于API。那么，如何处理这些实现依赖关系呢？
使用嵌入式依赖项选项，您可以拖动从maven pom中取出的所有传递性依赖项（这可能很多）。我不会使用它。它很快，但也很脏，因为您不知道自己拖了什么。
一般来说，我会仔细设计bundles。因此，bnd可以指定应包含在构建路径上其他工件的哪些包。甚至有一种方法可以让bnd计算特定命名空间所需的内容：
Conditional-Package: aQute.lib.*
这很少一次就能完美地运作，你会发现第一次运行时可能会遗漏某些内容，因此需要进行多次迭代。但至少你知道了你的 bundle 中有什么。
