3

我有一个想要包装的第三方 JAR - 它没有自己的 OSGi 清单。例如，org.myproject。所以我创建了一个捆绑包装器。

这很好用——我提供了org.myproject. 这是由org.myproject. 说，1.0.1。

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

但是，当使用 bndtools 包装 JAR 时，包导出的版本仍为1.0.1.

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

4

1 回答 1

2

我们在说什么版本？如果您在 bnd 中使用 1.2.3.XXXXX 对包进行版本化，那么这就是您将作为导出获得的包版本。

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

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

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

但是，这将是全球性的变化，我希望您对此感到遗憾。

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

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

当然，最简单的解决方案是结束它并接受将口红涂在猪身上并不会使其语义版本化。只需将版本与依赖项分开即可。在这些情况下，我倾向于选择一个奇怪的主要数字，例如 100，以明确我的版本不是目标的版本。

由于我对这些项目有一些不愉快的回忆，我还建议您看看OSGi 合同。使用合同，您无需对包进行版本控制，而是使用合同要求。

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

于 2016-02-29T10:01:03.393 回答