在OSGi中，使用版本号和版本范围时，定义的依赖项（即包导入和导出）的解析过程非常严格 . 如果对于某些软件包导入版本1.2.3没有找到包含1.2.3范围的相应导出，则无法解析或启动该软件包 . 这很好 .
但是，这似乎不适用于核心包 org.osgi.framework . Equinox（3.8.0）和Apache Felix（4.0.3）的当前版本将 org.osgi.framework,version=1.7.0 定义为导出的包之一 . 但是捆绑包需要该包的特定较低版本，例如 Import-Package: org.osgi.framework;version=1.3 ，仍然解决了这个更新的版本 . 我希望捆绑包不会得到解决 .
如何解释这种行为？这是OSGi实现的不当行为吗？我在解析核心OSGi包时错过了一个异常？或者卡拉夫在这里遇到阻碍（我用Apache Karaf进行了测试，见下文）
我知道我宁愿不明确声明版本，并且该版本会产生一个完全可解析的范围 . 但是，我不能控制定义此类导入的捆绑包（即：iPOJO，见下文） .
一些设置细节：我在Karaf 2.3.2和2.3.3中测试了它，分别启用了Equinox或Felix . 您可以找到我用于测试over at github的演示包，它可以按原样构建，并在部署到新的Karaf容器时显示失败 . 我发现这个的原因是因为core iPOJO bundle定义了这样的显式版本而不是范围 . 我将其添加到Karaf功能描述符，并尝试使用Karaf Features Maven Plugin验证功能导出/导入完整性，但失败了 .
2 回答
在OSGi中，version = 1.3的导入等同于version =“[1.3，∞）” . 请参见第3.2.6节“版本范围” . 这是出于历史原因 .
您应该始终在导入包语句中使用完整的版本范围 .
不，OSGi中的包导入不是，重复NOT，处理方式不同 . OSGi从不为自己的服务或代码制作例外，它是完全对称的 .
正如BJ在他的回答中所说，版本X的导入实际上是X的导入和任何更高的导入 .