我可以使用版本限定符来要求 OSGi 中的特定包版本吗？答案

【问题标题】：Can I use version qualifiers to require specific package versions in OSGi?我可以使用版本限定符来要求 OSGi 中的特定包版本吗？
【发布时间】：2016-05-31 01:48:27
【问题描述】：

我有一个想要包装的第三方 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 中管理此问题的最佳方法是什么？

【问题讨论】：

如果 org.myproject 发生了变化，为什么这不仅仅是你打包的包的版本提升？毕竟包装的内容变了。
好吧，如果我称它为1.0.2，然后org.myproject 的作者会在我已经包含的内容之外进行一些更改并调用that @987654331 @，我们有点吃醋了，不是吗？如果我想包装他们的新版本，我会称之为什么版本？
也许我认为捆绑版本应该镜像包装的 JAR 版本的想法不正确？
所以你最初包装了 org.myproject 的 1.0.1 并调用了你的包 1.0.1。然后 org.myproject 更改但没有将版本增加到至少 1.0.2？然后，您在尝试将语义版本包装在没有语义版本的项目周围时会遇到一些麻烦。 :-(
是的！ ;-) 回到正题——在这种情况下可以使用限定符吗？如果可以，我怎样才能让bnd 或bndtools 生成带有它们的导出语句？

标签： java osgi version bnd bndtools

【解决方案1】：

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

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

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

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

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

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

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

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

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

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

【讨论】：

谢谢彼得。我想我会简单地“克服它”——听起来我无论如何都试图绑定版本是错误的。