如何避免 karaf 加载默认的解析包

Question

我使用 karaf 运行一个 OSGI 包，它使用内置的 commons-lang3.5.jar。

问题是当我运行这个包时，karaf 会自动加载另一个 commons-lang3.1.jar。我不确定它什么时候加载。但这让我的捆绑包崩溃了。

有什么方法可以卸载 karaf 默认内置捆绑包？

Answer 1

不，不要“卸载”默认的内置包，因为它被其他人使用。 确保您自己的包对 commons lang 包进行了干净的导入。

bnd 指令如下所示：

import-package:
   org.apache.commons.lang;version="[3.5,4.0)", \
   *

如果有更好的版本可用，那么您可以确保仅导入 commons lang，然后您已经包含自己。

提示，不要嵌入依赖项，但要确保你依赖于可重用的依赖项。使用此类导入包，您可以确保您依赖于特定版本。

Answer 2

正如 Achim 所说，不要卸载默认包，但要指定所需的版本范围。但是，我建议您不要使用正常的 OSGI 版本范围，而是指定 [3.5.0,3.5.0]。

目前，仅使用点版本导入 COMMONS 包是最安全的，或者使用从您确定与使用 bnd 基线或类似的代码兼容的最低版本开始的版本范围，并以您正在构建的版本的完整版本号。

例如，忽略所有次要版本： 在 commons-lang 的 3.0 和 3.1 发布之间，唯一报告的基线 api 更改是两个包中的次要更改： org.apache.commons.lang3 和 org.apache.commons.lang3.exception。

但是，所有包都被撞到了3.1.0。

在从 3.1 到 3.2 之间，对几个包进行了细微更改：第二次小级别更改为 org.apache.commons.lang3，最初的小更改为 org.apache.commons.lang3.reflect、org.apache.commons.lang3.text、org.apache.commons.lang3.text.translate 和 org.apache.commons.lang3.tuple。

但是，org.apache.commons.lang3.time 发生了重大变化。

再一次，所有的包版本都设置为 3.2.0 ，除了现在的包版本没有过度限制，现在有一个隐藏的重大变化。

换句话说：将声明的导出包版本与基于基线检测到的更改的更“准确”的包版本进行比较，我们有以下结果。

请注意，对于仅具有微小更改的软件包，“准确”的软件包版本号反映的是对该软件包进行了微小更改的发行版数，而不是任何特定发行版的软件包编号。

包装 | “准确” |宣布 -------------------------------------------------- ---------------- = org.apache.commons.lang3 | 3.2.0 | 3.2.0 + org.apache.commons.lang3.builder | 3.0.0 | 3.2.0 + org.apache.commons.lang3.concurrent | 3.0.0 | 3.2.0 + org.apache.commons.lang3.event | 3.0.0 | 3.2.0 + org.apache.commons.lang3.exception | 3.1.0 | 3.2.0 + org.apache.commons.lang3.math | 3.0.0 | 3.2.0 + org.apache.commons.lang3.mutable | 3.0.0 | 3.2.0 + org.apache.commons.lang3.reflect | 3.1.0 | 3.2.0 + org.apache.commons.lang3.text | 3.1.0 | 3.2.0 + org.apache.commons.lang3.text.translate| 3.1.0 | 3.2.0 * org.apache.commons.lang3.time | 4.0.0 | 3.2.0 + org.apache.commons.lang3.tuple | 3.1.0 | 3.2.0

1 包的包号“正确”，10 包的包号太保守，1 包的包号错误。 如果我们一直遵循模式到 3.5，这将保持不变（在 3.4 和 3.5 之间对时间包进行第二次隐藏的重大更改：

包装 | “准确” |宣布 -------------------------------------------------- ---------------- = org.apache.commons.lang3 | 3.5.0 | 3.5.0 + org.apache.commons.lang3.builder | 3.3.0 | 3.5.0 + org.apache.commons.lang3.concurrent | 3.1.0 | 3.5.0 + org.apache.commons.lang3.event | 3.1.0 | 3.5.0 + org.apache.commons.lang3.exception | 3.2.0 | 3.5.0 + org.apache.commons.lang3.math | 3.2.0 | 3.5.0 + org.apache.commons.lang3.mutable | 3.2.0 | 3.5.0 + org.apache.commons.lang3.reflect | 3.4.0 | 3.5.0 + org.apache.commons.lang3.text | 3.3.0 | 3.5.0 + org.apache.commons.lang3.text.translate| 3.2.0 | 3.5.0 * org.apache.commons.lang3.time | 5.0.0 | 3.5.0 + org.apache.commons.lang3.tuple | 3.1.0 | 3.5.0

[ 在我打开一个关于 OSGI 版本问题的 commons-compress 问题后，我正在与一些 COMMONS 项目人员讨论包版本。对于这个项目，每个包的每个版本都与发布号相同（扩展为三位），并且都在 [1,2) 范围内。

folks commons 超级项目因 packageinfo 文件位于源目录中而挂起；可能是因为我从 src 树中添加了 packageinfo 文件的手动副本，这显然不再需要了。他们还希望包版本应该自动生成。

我还没有正确解释为什么 maven-bundle-plugin 默认使用每个包的发布版本是危险的，并且更改包版本应该由更改源的人以更改版本的方式完成（以避免意外的破坏性更改），基线验证作为一种单元测试。

具有讽刺意味的是，我提交更改是为了准备合并一些对 compress 的实质性贡献，这些贡献是为了帮助存储来自 maven Central 的每个声明的包，以便分析包版本号的可靠性，并查看如何在使用数据库支持的存储库时可以做很多事情来自动修复它们（并查看捆绑系列中是否有任何可以预测可靠性的特性）。 ]