【问题标题】:Best practices when dealing with OSGI & 3rd party libraries处理 OSGI 和 3rd 方库时的最佳实践
【发布时间】:2017-11-02 09:56:07
【问题描述】:

我正在努力寻找一种合理的方法来管理足够大的代码库,更具体地说,如何管理任何给定包的 import 语句。

问题是,如果你有一个捆绑包,它对其他 3rd 方库有自己的依赖项,并且如果你选择嵌入其中的一些(在我的情况下是这样做的),maven-bundle-plugin 也会扫描这些包库并通过你的包将它们添加为imported(这完全违反直觉)。

我的工作是在你的import 语句中去掉通配符*,但这意味着现在你必须手动维护导入列表。

那么你们是如何解决这个问题的呢?我在这里错过了什么吗?

任何建议将不胜感激

【问题讨论】:

    标签: java maven osgi maven-bundle-plugin


    【解决方案1】:

    捆绑非 OSGi 第三方库有时很困难。 maven-bundle-plugin 通常只嵌入和导入它发现正在使用的东西,从而做得很好。

    问题是很多库有很多依赖,尤其是很多可选的依赖。在这些情况下,maven bundle 插件通常会很小心,并且会导入不必要的内容。如果您确定不需要某些东西,您可以通过指定来禁止导入:

    Import-Packages: !somepackage, *

    我个人的做法是尽量避免使用具有大量外部依赖项的库。如果我无法避免它们,那么我会检查已经捆绑了许多库的 servicemix 包。

    【讨论】:

    • 这将是理想的,除非你想嵌入一些库,然后通配符 * 告诉 maven-bundle-plugin 也添加来自该库的包
    • 所以我之前的评论没有解决办法(嵌入库)?
    • 你也可以导出这些包吗?
    • 是的,但是你最终做了很多不必要的手动工作,我认为问题的根源是 maven-bundle-plugin,我真的不知道它为什么会生成来自嵌入式依赖项的导入语句
    • 但是我无法控制这些包的可见性,因为它们来自 3rd 方库
    猜你喜欢
    • 1970-01-01
    • 2010-10-07
    • 2011-12-16
    • 1970-01-01
    • 1970-01-01
    • 2013-08-25
    • 2017-08-09
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多