我使用 karaf 运行使用内置 commons-lang3.5.jar 的 OSGI 包。
问题是当我运行这个包时，karaf 会自动加载另一个 commons-lang3.1.jar。我不确定它什么时候加载。但这需要我的捆绑崩溃。
有什么方法可以卸载 karaf 默认内置捆绑包？
问问题
268 次
2 回答
1
不，不要“卸载”默认的内置包，因为它被其他人使用。确保您自己的包对 commons lang 包进行了干净的导入。
bnd 指令如下所示：
import-package:
org.apache.commons.lang;version="[3.5,4.0)", \
*
这样，如果有更好的版本可用，则确保仅导入 commons lang，然后是您自己已经包含的版本。
提示，不要嵌入依赖项，但要确保依赖于可重用的依赖项。使用此类导入包，您可以确保您依赖于特定版本。
于 2017-06-04T08:27:52.297 回答
1
正如 Achim 所说，不要卸载默认包，但要指定所需的版本范围。但是，我建议您不要使用正常的 OSGI 版本范围，而是指定 [3.5.0,3.5.0]。
目前，仅使用点版本导入 COMMONS 包是最安全的，或者使用从您确定与使用 bnd 基线或类似的代码兼容的最低版本开始并以完整版本号结尾的版本范围您正在构建的版本。
例如，忽略所有次要版本：在 release3.0和3.1commons-lang 之间，唯一报告的基线 api 更改是两个包中的次要版本：
org.apache.commons.lang3和org.apache.commons.lang3.exception.
然而，所有的包裹都被撞到了3.1.0。
在 from3.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
[ 在我为 commons-compress 打开一个关于 OSGI 版本问题的问题后，我正在与一些 COMMONS 项目人员讨论包版本。对于这个项目，每个包的每个版本都与发布号相同（扩展为三位数），并且都在 [1,2) 范围内。
民间公共超级项目因 packageinfo 文件位于源目录中而挂起；可能是因为我从 src 树中添加了 packageinfo 文件的手动副本，这显然不再需要了。他们还希望包版本应该自动生成。
我还没有正确解释为什么 maven-bundle-plugin 默认为每个包使用发布版本是危险的，并且更改包版本应该由更改源的人以更改版本的方式完成（以避免意外的重大更改），基线验证用作一种单元测试。
具有讽刺意味的是，我提交这些更改是为了准备合并一些对 compress 的实质性贡献，这些贡献是为了帮助存储来自 maven Central 的每个声明的包，以便分析包版本号的可靠性，并查看可以有多少完成以在使用数据库支持的存储库时自动修复它们（并查看捆绑系列中是否有任何可预测可靠性的功能）。]
于 2017-06-04T19:46:05.397 回答