如何避免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系列的任何功能），可以做多少工作來自動修復它們。 ]