我使用karaf来运行一个使用内置commons-lang3.5.jar的OSGI包。
问题是当我运行这个包时，karaf将自动加载另一个commons-lang3.1.jar。我不确定它什么时候加载。但是我的捆绑包会崩溃。
有没有办法卸载karaf默认的内置包？
答案 0 :(得分：1)
不，不要＆＃34;卸载＆＃34;默认的内置包因为其他人使用它。 确保您自己的bundle为commons lang bundle执行干净导入。
bnd指令看起来像：
import-package:
org.apache.commons.lang;version="[3.5,4.0)", \
*
这样一来，如果有更好的版本，那么你确保只导入公共语言，然后你自己已经包含了。
提示，不要嵌入依赖项，但要确保依赖可重用的依赖项。使用此类导入包，您可以确保依赖于特定版本。
答案 1 :(得分：1)
正如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，除了现在而不是包版本过于严格，现在有一个隐藏的重大变化。
换句话说：将声明的出口包版本与更多＆＃34;准确的＆＃34;进行比较。基于基线检测到的更改的包版本，我们有以下内容。
请注意，对于仅进行微小更改的套餐，＆＃34;准确＆＃34;软件包版本号反映了对该软件包进行微小更改的版本数量，而不是任何特定版本的软件包编号。
Package | "Accurate" | Declared ------------------------------------------------------------------ = 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
包裹编号是＆＃34;正确＆＃34;对于1个包，对于10个包非常保守，对于1个错误。 如果我们一直遵循3.5的模式（第二次隐藏的MAJOR更改为3.4和3.5之间的时间包，则保持不变：
Package | "Accurate" | Declared ------------------------------------------------------------------ = 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项目人员的讨论中，在我打开关于OSGI版本问题的commons-compress问题之后。对于这个项目，每个包的每个版本都与版本号相同（扩展到三位数），并且都在[1,2]范围内。
关于包含在源目录中的packageinfo文件的人们对超级项目感兴趣;可能是因为我从src树中添加了一个packageinfo文件的手册副本，显然不再需要了。他们还希望自动生成包版本。
我还没有正确解释为什么maven-bundle-plugin默认使用每个软件包的发布版本是危险的，更改软件包版本应该由更改源代码的人来完成版本（以避免意外破坏更改），基线验证作为一种单元测试。
具有讽刺意味的是，我提交了这些更改作为准备合并一些实质性贡献的一部分，用于压缩，以帮助存储来自maven中心的每个已声明的包，以分析包版本号的可靠性，并了解如何在使用数据库支持的存储库时，可以做很多事情来自动修复它们（并查看是否有任何捆绑系列的功能是可靠性的预测因子）。 ]