40-50個のOSSパッケージに依存する大規模な（> 500,000 LOC）Javaシステムがあります。システムはAntで構築されており、依存関係の管理は現在手動で処理されています。依存関係を自動化するために、IvyやMavenを調査しています。昨年、Mavenをビルドオートメーションシステムと見なして、Mavenのアーキテクチャに一致するようにシステムを完全に再構築する必要があるため、それを拒否しました。現在、依存関係管理タスクのみを自動化しようとしています。
私はIvyでいくつかの実験を行いましたが、問題が発生しました。たとえば、依存関係としてActiveMQを指定し、依存関係の指定にMavenリポジトリーのPOMを使用するようにIvyに指示すると、Ivyは一連のパッケージ（Jetty、Derby、Geronimoなど）を取得します。 ActiveMQを使用します。
ivysettings.xmlでusepoms = "false"を設定すると、activemq.jarのみがフェッチされますが、それはIvyの目的に反しているようで、手動で作成した依存関係の仕様を持つ単純なjar-fetcherにそれを委任します。
ここには大きな問題があります。Windowsでは「DLL Hell」と呼ばれていました。場合によっては、2つの直接的な第1レベルの依存関係が、同じ推移的な依存関係の異なるバージョンを指します（たとえば、log4j.jar）。クラスパスに含めることができるlog4j.jarは1つだけなので、依存関係の解決には、システム内のすべてのクライアントと互換性のあるバージョンを手動で決定する必要があります。
それはすべて、各パッケージの依存関係仕様（POM）の品質に帰着していると思います。ActiveMQの場合、スコープ宣言がないため、ActiveMQへの参照は、必要でないとわかっている依存関係を手動で除外しない限り、その依存関係をすべてダウンロードします。
log4jの場合、依存関係の自動解決には、log4jのすべてのクライアント（log4jに依存する他のパッケージ）が以前のすべてのバージョンのlog4jに対して検証し、POMで互換性のあるlog4jバージョンの範囲（またはリスト）を提供する必要があります。それはおそらく質問するのが多すぎます。
これは現在の状況ですか、それとも何か不足していますか？
あなたはそれを言うのは全く正しい
それはすべて、各パッケージの依存関係仕様（POM）の品質に帰着していると思います。
追加するのは、POMまたはその他の形式のメタデータを開始点として表示することだけです。たとえば、ActiveMQがすべての依存関係を提供することは非常に便利ですが、実際にプロジェクトに適しているかどうかはユーザーが選択する必要があります。
結局のところ、log4jのバージョンを考慮に入れても、外部の依存関係でバージョンを選択するのか、それとも動作することがわかっているバージョンを選択するのか？
依存関係の調整を選択する方法については、Ivyでできることは次のとおりです。
Ivyは、ActiveMQを使用するだけでは必要ないことがわかっている多数のパッケージ（Jetty、Derby、Geronimoなど）を取得します。
これは通常、アプリケーションのモジュール性が低いために発生します。たとえば、アプリケーションの一部でJettyが必要ですが、使用しない場合でも、この一時的な依存関係が発生します。
おそらく、ツタの除外メカニズムを調べたいと思います。
<dependency name="A" rev="1.0">
<exclude module="B"/>
</dependency>
クラスパスに含めることができるlog4j.jarは1つだけなので、依存関係の解決には、システム内のすべてのクライアントと互換性のあるバージョンを手動で決定する必要があります。
おそらく私はこれを誤解しているかもしれませんが、Ivyの競合解決には手動の要素はありません。デフォルトの競合マネージャーのリストがあります。
必要に応じて、独自の競合マネージャーを提供できます。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加