根据Introduction to the bnd workspace model，存储库定义了一组确切的依赖关系，不支持传递性依赖关系，因为它们倾向于使OSGi系统变得可怕。
在正确的情况下，有人可以提供更详细的解释（高度赞赏使用具体用例吗？我想这主要与清单中正确的Import-Package列表有关。应该如何处理传递依赖项？有没有办法提供所有必需的进口商品？
这是否意味着仅maven包开发（使用bnd-maven-plugin或maven-bundle-plugin）更容易出错，因为maven支持传递依赖项？在这种情况下应如何处理传递依赖项？
谢谢！
在OSGi捆绑包中，创建和应用程序组装是两个非常不同的东西。当使用maven创建包时，您当然会使用传递依赖。 maven-bundle-plugin或bnd-maven-plugin的结果是jar清单中的条目。他们定义了诸如导入或导出包之类的东西。此结果不包含传递依赖项。这些捆绑包可以在工作区模型和Maven模型中使用。
应用程序组装是一个不同的过程。在那里，您建立了一个如此完善的存储库，其中列出了可能要安装的捆绑软件。在工作空间模型中，您列出了没有传递依赖项的每个包。在基于Maven的应用程序程序集中，您使用pom的依赖项定义存储库。在那里使用传递依赖。
之所以传递依赖关系并不总是那么好，是因为捆绑软件的依赖关系通常不是您要在应用程序中使用的依赖关系。因此，maven模型具有将有问题的捆绑软件添加到存储库的潜力。这些依赖关系可能会减慢对要使用的实际捆绑包的解析，甚至导致无法正常工作的已解析捆绑包。幸运的是，您可以使用通常的maven排除方法排除某些传递依赖项来解决此问题。
根据我的个人经验，传递性捆绑对于应用程序组装通常非常有用，因为您不必手动列出所有依赖项。有问题的情况不太容易解决。因此，我不同意不应利用传递依赖。