什么时候应该使用导入包,什么时候应该使用需要捆绑包?

我相信 Require-Bundle 是一个Eclipse的东西(它现在已经在OSGi规范中用于容纳Eclipse)。“纯”的OSGi方法是使用 Import-Package ,因为它专门将包与提供它的包分离。您应该声明依赖于您需要的功能(由某个软件包的某个版本提供的Java API),而不是该功能来自何处(这对您不重要)。这使捆的组成更加灵活。

JavaScript类比:这类似于检测Web浏览器是否支持某个API,而不是从用户代理字符串中推断出它是哪种浏览器。

OSGi联盟的Peter Kriens在 OSGi blog .

可能是唯一需要使用的情况 依赖项 如果您有拆分的包,这是一个分布在多个包中的包。当然,不鼓励分开包装。

赞成进口包装而不是要求捆绑包装。

需要捆绑:

• 指定要使用的显式绑定(和版本)。如果需要重构一个Required捆绑包并将一个包移到别处,那么依赖项将需要更改其manifest.mf。
• 允许您访问包的所有导出,不管它们是什么,也不管您是否需要它们。如果不需要的部分有自己的依赖关系,则需要这些依赖关系
• 捆绑包可以重新导出
• 尽管不鼓励,但允许使用拆分包,即:分布在多个包中的包
• 可用于非代码依赖项,例如:资源、帮助等。

进口包装:

• 松耦合,只指定包(和版本),运行时找到所需的包
• 实际的实现可以被剔除
• 依赖包的所有者可以将其移动到不同的包中
• 但需要在较低的粒度级别维护更多的元数据(即:每个包名称)

我相信进口包装给你更松的耦合,应该是首选。我在声明对我不拥有的包(如SLF4J)的依赖性时使用它,并且我可以根据自己的意愿交换实现。当依赖关系是我可以控制的东西时,我使用RequireBundle,例如我自己的bundle,因为任何重要的更改都会经过我自己。

避免导入包。 由于包在包之间提供多对多的关系,因此它们容易出现难以检测和避免的依赖循环。

另一方面,需要bundle,引用单个bundle,通过简单的构建时检查使依赖关系图免受周期的影响。 使用RequireBundle,使用独立的较低抽象级别构建分层架构要容易得多。

Import-Package 应该更好,因为正如前面所说,您可以将包从一个包移动到另一个包,而不必更改现有客户机的manifest.mf。

但是…

有实际的理由使用 Require-Bundle 如果使用Eclipse开发包:

Eclipse不使用包作为分辨率单位。它使用捆绑包。也就是说,如果您使用一个包中的一个包,那么Eclipse会编译您的包,而不会报告其他未从该包中导入的包的使用有任何问题。

你可以(你是人类)认为一切正常,上传你的包进行部署,但是…您的包将在运行时中断。

我很肯定,因为这个问题(对我)已经发生了!今天。

好的解决方案是更改Eclipse类路径容器,但是…如果不这样做…您可以决定避免这种需要捆绑包而不是包的问题,并支付所提到的价格(捆绑包之间没有向后兼容的代码移动)。

我不相信使用导入包更好,因为我在处理包时的默认期望是使用相关的公共API。因此,需要捆绑包更有意义。