Question

我有一个我希望包装的第三方JAR - 它没有自己的OSGi清单。例如，org.myproject。 So I create a bundle wrapper.

这很好用 - 我提供了org.myproject版本的版本。这由org.myproject的作者决定。说，1.0.1。

现在，org.myproject已更改，我想要包含更改。但是，目前还没有官方发布。这听起来像我可以使用限定符来表示更新的版本：1.0.1.$timestamp

但是，在使用bndtools包装JAR时，包导出仍然版本为1.0.1。

是否可以在OSGi中导出然后导入特定于限定符的包版本？在bndtools中管理这个的最佳方法是什么？

Answer 1

我们在谈论什么版本？如果您使用1.2.3.XXXXX在bnd中对软件包进行版本控制，则这是您将作为导出获得的软件包版本。

但是，默认情况下，bnd在根据导出创建导入范围时剥离限定符。您应该能够使用版本策略覆盖它。默认值为：

-provider-policy    = ${range;[==,=+)}
-consumer-policy    = ${range;[==,=+)}

您可以轻松更改它们以包含限定符。

然而，这将是一次全球变化，我希望你对此感到遗憾。

所以另一个解决方案是修改这个坏包的导入：

Import-Package org.myproject;version="${range;[====.=+);${@}}", *

当然，最简单的解决方案就是将其解决并接受将唇膏放在猪身上并不能使其在语义上版本化。只需使用依赖项将您的版本与您的捆绑包分开。在那些情况下，我倾向于选择一个奇怪的主要数字，例如100，要明确我的版本不是目标版本。

由于我对这些项目有一些讨厌的回忆，我还建议你去看看OSGi contracts。对于合同，您不会对包进行版本设置，但是您使用合同要求。

然后是最后一个，绝对是最好的，你真的需要该项目进行版本控制吗？我发现在大多数情况下，开发我自己的OSGi API非常值得反映我对这个外部目标的需求。然后我可以把那个包很好地隐藏在一个黑暗的地方，它可能因为没有语义版本而受到影响： - ）