在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验证功能导出/导入完整性。
答案 0 :(得分：4)
在OSGi中，版本= 1.3的导入等同于version =“[1.3，∞）”。请参见第3.2.6节“版本范围”。这是出于历史原因。
您应该始终在导入包语句中使用完整的版本范围。
答案 1 :(得分：0)
不，OSGi中的包导入不是，重复NOT，处理方式不同。 OSGi从不为自己的服务或代码制作例外，它是完全对称的。
正如BJ在他的回答中所说，版本X的导入实际上是X和更高版本的导入。