karafを回避する方法デフォルトの解決バンドル

Question

karafを使用して、組み込みのcommons-lang3.5.jarを使用するOSGIバンドルを実行します。

このバンドルを実行すると、karafは別のcommons-lang3.1.jarを自動的にロードします。私はそれがいつロードされるのか分かりません。しかし、それは私のバンドルクラッシュを取る。

karafのデフォルトビルトインバンドルをアンインストールする方法はありますか？

Answer 1

いいえ、他の人が使っているデフォルトの組み込みバンドルを「アンインストール」しないでください。 自分のバンドルがcommons langバンドルのクリーンインポートを行っていることを確認してください。

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

あなたは、利用可能なより良いバージョンがすでに自分自身が含まれている1がある場合にのみコモンズラングをインポートすることを確認し、このように：

BND命令は次のようになります。

ヒントは、依存関係を埋め込むことはしませんが、再利用可能な依存関係に依存していることを確認してください。このようなインポートパッケージを使用すると、特定のバージョンに依存していることを確認できます。

Answer 2

Achimによると、デフォルトのバンドルはアンインストールしないでください。必要なバージョンの範囲を指定してください。しかし、通常のOSGIのバージョン範囲を使用せず、代わりに[3.5.0,3.5.0]を指定することをお勧めします。

現時点では、ポイントバージョンを使用してCOMMONSバンドルをインポートするか、bndベースラインなどを使用してコードと互換性があると判断した最低バージョンから始まるバージョン範囲を使用してインポートするのが最も安全ですビルドしているバージョンのフルバージョン番号。例えば

は、すべてのマイナーリリースを無視： org.apache.commons.lang3とorg.apache.commons.lang3.exception：リリース3.0とコモンズ - ラングの3.1間 を、唯一のベースラインは、APIの変更は、2つのパッケージで未成年だったと報告しました。

ただし、すべてのパッケージは3.1.0にバンプされています。 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への最初の小さな変更：3.1から3.2の間

は、いくつかのパッケージに若干の変更がありました。

しかし、メジャーが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へのパターンに従うなら、これは変わりません（第2隠し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 

[私はOSGIバージョンの問題についてコモンズ、圧縮のために問題を開いた後、私は、パッケージのバージョンについてCommonsプロジェクトの人々の何人かとの議論にいるよ。このため。プロジェクトでは、すべてのパッケージのすべてのバージョンがリリース番号（3桁まで拡張）と同一であり、すべてが範囲内にあります[1,2]。

あなたのスーパープロジェクトは、ソースディレクトリにあるpackageinfoファイルについてハングアップしています。 srcツリーからpackageinfoファイルのマニュアルコピーを追加したためです。これは明らかにもう必要ではありません。また、パッケージのバージョンを自動的に生成することをお勧めします。

すべてのパッケージにリリースバージョンを使用するデフォルトのmaven-bundle-pluginのデフォルトが危険で、パッケージのバージョンを変更するのは、ソースを変更する人が変更する必要がある理由をまだ正しく説明していませんバージョン（偶発的な変更の破損を防ぐため）、ベースライン検証は一種の単体テストとして機能します。

皮肉なことに、私は、圧縮されたすべてのバンドルをMavenから中央に格納するのを助けるために、いくつかの実質的な圧縮にマージする準備の一環として、パッケージのバージョン番号の信頼性を分析し、データベースバックアップされたリポジトリを使用しているとき（そして信頼性の予測子であるバンドルシリーズの機能があるかどうかを確認するために）、それらを自動的に修正するためにどれくらいの労力がかかります。 ]