web-dev-qa-db-ja.com

依存バージョンの競合を回避しますか?

私のjarを使用するすべてのJavaプロジェクトは、ほぼ確実に、私のjarにも依存関係として含まれている別のjarへの追加の依存関係があります。

問題は、他のjarに複数のバージョンがあることです。

プロジェクトの2番目のjarのバージョンが私のjarの2番目のjarのバージョンと異なる可能性が高い場合に、発生する可能性のある問題を回避するにはどうすればよいですか?

私のjarファイルを追加するために、ユーザーが特別なクラスローディングトリックを行う煩わしさを感じたくありません。

その共通の依存関係のすべての可能なバージョンについて、jarのさまざまなバージョンの束を作成する必要がありますか?そして、あなたはちょうどあなたがたまたま持っている2番目のjarの同じバージョンを使用する私のjarのバージョンを選択するだけですか?

これを処理するよりスマートな方法はありますか、そして競合なしに人々が私のjarをより簡単に使用できるようにしますか?

10
Dingredient

それはyourの問題ではありません。解決するのはエンドユーザー次第です。サードパーティの依存関係を使用する領域が付属しているだけなので、依存関係の競合を数回解決する必要がありました。すべてのプロジェクトの特定の依存関係の競合に対応することは期待できません。

ソフトウェアは、最新バージョンの依存関係で正しく動作するはずです。依存関係がすべてのリリースでインターフェースを変更していない限り、互換性の範囲が必要です(たとえば、ソフトウェアは範囲内のすべてのバージョンのdepで機能します[2.0.0, 3.0.0))。ソフトウェアを保守している限り、すべての依存関係の最新バージョンとの互換性を保つようにしてください。

そうは言っても、ここに私があなたのソフトウェアを私の依存関係の異なるバージョンで使用している開発者として役立つと思うことがいくつかあります。

  • プロジェクトと別のプロジェクトの統合が緊密である場合、ドキュメントに互換性チャートを含めると役立ちます。とにかく、ドキュメントで依存関係の特定のバージョンに関する既知の問題について言及する必要があります。そうでなければ、開発者は試行錯誤によって互換性のあるバージョンを見つける必要があります。
  • インターフェースを介して依存関係とのコラボレーションを抽象化し、実装を依存関係注入で置き換えることができるようにソフトウェアを設計します。これにより、エンドユーザーとして、私を煩わすことなく、自分の統合をライブラリのバージョンxに置き換えることができます。
  • ユーザーが共通の依存関係の特定のバージョンをサポートするように依頼できるように、公開の問題トラッカーを用意します。多くのユーザーが、互換性のないバージョンの依存関係のサポートを求めている場合は、両方のバージョンを公開できます。 このMavenの例 を参照してください。これらは複数のプラットフォームを対象としています-依存関係の異なるバージョンのサポートは類似しているはずです。
10
Samuel