在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。您可以在 github 上找到我用于测试的演示包，它可以按原样构建，并且在部署到新的 Karaf 容器时会显示失败。我发现这一点的原因是，核心 iPOJO 捆绑包定义了这样的显式版本而不是范围。我将其添加到 Karaf 特征描述符中，并尝试使用 Karaf 功能专家插件验证功能导出/导入完整性，但失败了。
在 OSGi 中，导入 version=1.3 等效于 version="[1.3，∞("。请参见第 3.2.6 节 "版本范围"。这是出于历史原因。
应始终在导入包语句中使用完整的版本范围。
不，OSGi 中的软件包导入不是，重复不是，处理方式不同。OSGi从不为自己的服务或代码设置例外，它是完全对称的。
正如BJ在他的回答中所说，版本X的导入实际上是X和更高版本的导入。