OSGiMaven依赖项vs导入包vs嵌入依赖项

有谁能告诉我这两者的区别吗

依赖项vs导入包vs嵌入依赖项

我真的看不懂示例osgi捆绑包的pom文件了

如果默认maven

*

语句解析对其他捆绑包的依赖关系

为什么需要使用

元素包含捆绑包

编辑：我没有任何样本放在这里。

---

问题是“如何将捆绑包连接为依赖项，以访问不同捆绑包中的包->服务？”

Maven提供了广泛的依赖项模型。一个项目有一个pom，pom指定它对其他pom的依赖关系。这是可传递的，因此只有一个依赖项可以下载一半的internet。在maven中，您可以指定在编译类路径或运行时类路径上需要依赖项

在OSGi中，您应该创建一个可以在不同环境中使用的包。因此，bundle是一个JAR，它使依赖项显式化。就像Maven一样，您可以让一个bundle依赖于另一个bundle（requirebundle）。然而，需要另一个捆绑包是相当脆弱的

• 它倾向于创建大型依赖关系图
• 您很容易遇到需要在不同版本中创建相同工件的情况
• 你需要的方式很多，因为你通常只需要另一个包的一部分
• 通常，您喜欢使用不同的实现

因此，OSGi有一个基于功能的本机依赖关系模型。包导出是一种能力。在OSGi中，Bundle A不依赖于Bundle B，而是依赖于包B。（并且包应该表示一个合同/API。）任何导出包b的包都将满足包a。此模型有许多优点，其最大的优点是它不可传递。这为部署时间提供了极大的灵活性

在OSGi中，一个关键目标是最小化依赖性，只依赖于定义良好的API，而不是实现，因此捆绑包在许多不同的上下文中都很容易使用

那么在maven中如何构造它呢

通常，您可以让bnd分析您的代码。然后，它将创建一个清单，精确地表示包所依赖的包

然而，开放源码中许多代码的构造方式可能不仅仅依赖于API。那么，如何处理这些实现依赖关系呢

使用“嵌入依赖项”选项，您可以将maven pom中的所有可传递依赖项（可能很多）都拖入。我不会用这个。它很快，但也很脏，因为你不知道你在拖什么

一般来说，我会仔细设计包。因此，bnd可以指定应该包括构建路径上其他工件的哪些包。甚至有一种方法可以让bnd计算特定名称空间所需的内容：

   Conditional-Package: aQute.lib.*

---

这在第一次运行时很难做到完美，您会发现在第一次运行时就错过了一些东西，因此需要进行一些迭代。不过，至少你知道你的包里有什么。

我不明白。你能再具体一点吗？也许有一个pom样本和你不明白的地方。