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

Question

我使用karaf来运行使用内置的commons-lang3.5.jar的OSGI包。

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

有没有任何方法可以卸载karaf默认的内置软件包？

Answer 1

不，不要“卸载”默认的内置包，导致其他人使用它。 确保你自己的包为commons lang包做了一个干净的导入。

一个BND指令看起来像：

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

这种方式，你要确保你只导入公郎是否有可用一个更好的版本，那么你已经列入自己一个。

提示，不要嵌入依赖项，但要确保依赖于可重用的依赖项。有了这样的导入包，你可以确保你依赖于特定的版本。

Answer 2

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

目前，仅使用点版本导入COMMONS捆绑包，或者使用版​​本范围从最低版本开始并使用bnd基准或类似方法与您的代码兼容并以您正在构建的版本的完整版本号。

例如，忽略所有次要版本： 发布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，除了现在，而不是软件包版本过于严格，现在有一个隐藏的重大更改。

换句话说：根据基线检测到的变化，将声明的导出包版本与更“精确”的包版本进行比较，我们得到以下结果。

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

 
    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 

包装号是“正确的” 1包，太保守了10包，以及错误的1 如果我们遵循的模式一路3.5（与第二隐瞒重大变化，这仍然不变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 

[我在与一些公共项目的人有关包版本的讨论中，我打开了关于OSGi版本问题公地压缩的问题后，对于这个。项目中，每个软件包的每个版本都与版本号相同（扩展到三位数），并且都在该范围内[1,2）。

乡下人的commons super-project挂起了关于packageinfo文件在源目录中;可能是因为我从src树中添加了packageinfo文件的手动副本，这显然不再需要。他们还希望应该自动生成软件包版本。

我还没有正确解释为什么Maven-bundle-plugin默认使用每个软件包的发布版本是危险的，并且更改软件包版本应该由更改源代码的人以改变版本（以避免意外中断更改），基线验证作为一种单元测试。

具有讽刺意味的是，作为准备合并的一部分，我提交了一些压缩的实质性贡献，这些贡献是为了帮助存储maven central的每个声明包，以便分析软件包版本号的可靠程度，以及查看在使用数据库支持的存储库时（以及查看是否有可用于预测可靠性的bundle系列的任何功能），可以做多少工作来自动修复它们。 ]