如何避免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)", \
   *

這樣，如果有更好的版本可用，那么請確保僅導入common 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，除了現在不是軟件包版本過於嚴格之外，現在有一個隱藏的重大更改。

換句話說：根據基線檢測到的更改，將聲明的導出軟件包版本與更“准確”的軟件包版本進行比較，我們得到以下內容。

請注意，僅對於具有較小更改的軟件包，“准確”的軟件包版本號反映對該軟件包進行較小更改的發行版數量，而不是任何特定發行版的軟件包編號。

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版本問題的commons-compress問題之后，我正在與一些COMMONS項目人員討論軟件包版本。 對於此項目，每個軟件包的每個版本都與發行版編號相同（擴展為三位數），並且都在[1,2]范圍內。

公眾共同體超級項目掛斷了packageinfo文件在源目錄中的情況。 可能是因為我從src樹中添加了packageinfo文件的手動副本，顯然不再需要了。 他們還希望軟件包版本自動生成。

我尚未正確解釋為什么對於每個軟件包都使用發行版的maven-bundle-plugin默認值很危險，並且更改軟件包版本應由更改源的人員以更改版本的方式來完成（以避免意外更改），並使用基准驗證作為一種單元測試。

具有諷刺意味的是，我提交這些更改是為了准備合並一些實質性的壓縮文件，以幫助存儲來自Maven Central的每個聲明的軟件包，以便分析可靠的軟件包版本號，並查看有多少版本。在使用數據庫支持的存儲庫時自動修復它們（並查看捆綁包系列是否有任何功能可預測可靠性）。 ]