在软件包版本明显不匹配的情况下，SLF4J OSGi如何工作？

在我看过的1.6.0之后的所有版本的SLF4J中，SLF4J api MANIFEST.MF如下所示（见1.7.21）：

但后端（如slf4j-log4j12）表示：

这不适合一起，它导致未解决的封装布线

我知道很多人在OSGi中使用SLF4J。见鬼，我使用了它，而且它很有效，但是pax日志可能掩盖了这个问题。我错过什么了吗

Import-Package: org.slf4j.impl;version=1.6.0

在导入包时指定确切版本意味着版本1.6.0或更高版本。因此，此行不会导致未解析的包

然而，所有的SLF4J实现包也需要API。通过这个规则，我们得到了一个循环依赖。SLF4J通过将每个实现捆绑包作为API的片段捆绑包来解决这个问题

在每个实现包中，您都可以看到以下内容：

Fragment-Host: slf4j.api

及

基于清单头：实现捆绑包的版本必须至少为1.6.0，API捆绑包的版本必须至少与实现捆绑包的版本一样大

在导入包时指定确切版本意味着版本1.6.0或更高版本。因此，此行不会导致未解析的包

然而，所有的SLF4J实现包也需要API。通过这个规则，我们得到了一个循环依赖。SLF4J通过将每个实现捆绑包作为API的片段捆绑包来解决这个问题

在每个实现包中，您都可以看到以下内容：

Fragment-Host: slf4j.api

及

---

基于清单头：实现捆绑包的版本必须至少为1.6.0，API捆绑包的版本必须至少与实现捆绑包的版本一样大。

Oh。我认为您需要[1.6.0,2.0]才能获得“至少”。但现在我知道得更清楚了。从osgi核心规范：

API的使用者因此应该导入一个范围，该范围从基本版本开始，以下一个主要更改结束，例如：[4.2,5）.API的提供程序应导入一个范围，该范围从基础版本开始，直到下一个小更改，例如：[4.2,4.3）。

。此外：

如果将版本范围指定为单个版本，则必须将其解释为范围[version，∞).

另外，如果您在导入包中根本没有指定版本，则会推断出范围

[0.0.0，无穷大）

。换句话说，它将解析为任何版本。哦，我以为您需要[1.6.0，2.0）以获得“至少”。但现在我知道得更清楚了。从osgi核心规范：

API的使用者因此应该导入一个范围，该范围以基本版本开始，以下一个主要更改结束，例如：[4.2,5]。API的提供者应该导入一个范围，该范围从基本版本开始，直到下一个次要更改，例如：[4.2,4.3.

。另外：

如果将版本范围指定为单个版本，则必须将其解释为范围[version，∞).

另外，如果您在导入包中根本没有指定版本，则会推断范围

[0.0.0，无穷大）

。换句话说，它将解析为任何版本。

Fragment-Host: slf4j.api

Import-Package: org.slf4j;version=1.7.21,...