著者：プラチナポセイドン
元のリンク：https://www.cnblogs.com/bryan31/p/13408479.html
序文
プロジェクトで全員がMavenのJarパッケージの競合の問題に遭遇している必要があります。一般的なシナリオは次のとおりです。
ローカルで実行すると、NoSuchMethodErrorおよびClassNotFoundExceptionが報告されます。明らかに、依存関係にこのJarパッケージがあります。なぜ実行できないのですか？？
プロジェクトでは、特定のjarパッケージバージョンを2.0.2として明確に定義していますが、パッケージ化した後、それを2.5.0にするにはどうすればよいでしょうか。？
Aプロジェクトはxxx.jarパッケージをインポートして正常に実行され、Bプロジェクトもxxx.jarをインポートしてエラーが報告されました。。Bプロジェクトまたはxxx.jarパッケージに問題がありますか？？
ローカル環境とテスト環境は正常に動作しています。本番環境の場合、一連のNoSuchMethodErrorsが報告されます。キャラクターや本番環境に問題はありますか？？
Mavenの依存関係メカニズムに詳しくない学生がこのような問題を調査すると、頭痛の種になります。
さらに、mavenは構造化されていないプロジェクトに依存しており、新しいJarパッケージを導入するリスクも非常に大きくなります。小さいものはパフォーマンスに影響を与えますが、大きいものは製品リリースとランタイム例外を引き起こします。
実際、上記の問題の根本的な原因はすべて、MavenのJarパッケージの競合と依存関係配信の不適切な使用に起因しています。この記事では、次の3つのコンテンツを分析します。
- 配達に依存する原理とジャーパッケージの衝突を引き起こす原理の分析
- 競合を特定してJARパッケージの競合を解決するためのいくつかの簡単な手法
- 依存関係のないPOMファイルを作成する方法
依存関係転送の原則
ほとんどすべてのJarパッケージの競合は依存関係の転送の原則に関連しているので、まずMavenの依存関係の転送の原則について説明しましょう。
最短経路の第一原理
2つのJarパッケージAとBが導入された場合、どちらもJarパッケージZに推移的に依存します。
A-> X-> Y-> Z（2.5）
B-> X-> Z（2.0）
実際、最終的に有効になったバージョンはZ（2.0）でした。彼の道はより短いからです。Z（3.0）パッケージをローカルで参照すると、3.0バージョンが有効になります。同じ理由。
最初に優先順位の原則を宣言する
パスの長さが同じ場合は、最初に宣言されたパスが優先されます。
A-> Z（3.0）
B-> Z（2.5）
ここで、Aが最初に宣言するため、渡されたZはバージョン3.0を使用することを選択します。
jarパッケージの競合の原則
プロジェクトが2つのJarパッケージAとBに依存しているとします。また、AとBにはそれぞれ次の推移的な依存関係があります。
A-> X-> Z（2.0）
B-> X-> Y-> Z（2.5）
次に、最終的なシステムでZパッケージが競合し、2.0と2.5の2つのバージョンが競合します。ただし、Zパッケージの1つのバージョンのみがクラスパスに依存しています。推移的な依存関係の最短経路優先原則によると、最終的な依存関係はバージョン2.0である必要があります。
Zパッケージの2.5バージョンの新しいメソッドがYパッケージで使用されている場合、このロジックが実行されます。NoSuchMethodErrorを報告します。もともとバージョン2.5に依存していたが、Jarパッケージの競合のため、Mavenはバージョン2.0を選択しましたが、バージョン2.0には新しいメソッドがなく、エラーが発生しました。
ただし、すべての競合が異常な動作を引き起こすわけではないことに注意してください。それどころか、同社のプロジェクトのほとんどで、Jarパッケージの競合が発生しますが、実行時の問題は発生しません。
これは、バージョン2.0でもバージョン2.5でも、推移的に依存する多くのJarパッケージが実行できるためです。
Jarパッケージの上位バージョンのみが下位互換性がないか、下位バージョンで使用できない新しいAPIの一部がこの問題を引き起こす可能性があります
位置の矛盾
IDEAはMaven依存関係分析成果物を提供します：Maven Helper
このプラグインを使用して、プロジェクト内のすべての依存関係ツリーと競合を表示します。
ここで赤く強調表示されている部分は、Jarパッケージに競合があることを示しています。このjarパッケージを選択すると、2つのバージョン間の競合の原因を確認できます。
上の図の例は、cruiser-clientのJarパッケージにバージョン2.5.0とバージョン4.0.1の2つの推移的な依存関係があることを示しています。競合の説明は次のとおりです。
2.5.0との競合の場合は省略2.5.0との競合の場合は省略
特定のレベルも右側に明確であるため、mavenは最短経路の第一原理に基づいて最終的にバージョン2.5.0 を選択し、バージョン4.0.1は無視されました。
現時点では、一部の学生は次のように質問します。Mavenヘルパーを使用して、ローカル環境を見つけることができます。運用前または運用環境についてはどうでしょうか。IDEAなしで、競合の詳細を見つける方法は？
あなたはmvnコマンドを使って解決することができます：
mvn dependency：tree -Dverbose
ここで-Dverboseパラメーターを省略しないでください。省略すると、無視されたパッケージが表示されません。
実際、mvnコマンドラインも同じくらい簡単に使用できます。非常に明確な。
JARパッケージの競合を解決するためのいくつかの実用的な手法
除外
上記の例でも、4.0.1を有効にしたい場合は2.5.0が有効です。2.5.0で[除外]をクリックするだけです。
バージョンロック
多くの依存関係がJarパッケージAに渡される場合、多くのバージョンが関係しますが、指定するバージョンは1つだけです。除外の方法で1つずつ除外するのは面倒であり、除外はpomファイルに反映されます。多すぎると、コードの清浄度と読み取りエクスペリエンスにも影響します。
現時点では、バージョンロック方式を使用する必要があります
バージョンロックとは何ですか？会社のプロジェクトには通常、親pomがあります。次のように、プロジェクトの親POM（もちろん、このプロジェクトで定義することもできます）で指定するバージョンを指定するだけで済みます（または、前の例では、バージョン4.0.1を指定します）。
<dependencyManagement>
<dependency>
<groupId>org.apache.curator</groupId>
<artifactId>curator-client</artifactId>
<version>4.0.1</version>
</dependency>
</dependencyManagement>
ロックされたバージョンのメソッドは、最も高い優先順位で、依存関係転送の2つの原則を破ることができます
バージョンがロックされると、依存関係ツリーは次のようになります。
これらはすべて4.0.1に統一されています。バージョンをロックすることには利点があります。バージョンロックはJarパッケージを除外せず、一貫性のないすべてのJarパッケージを統一されたバージョンに表示します。多くの除外タグに耐える必要はありません。
依存関係のないPOMファイルを作成する方法
私は穏やかなコードの清潔さを持っている人なので、pomファイルの依存関係もクリーンで整頓したいと思っています。クリーンなPOMを作成する方法、著者は注意するいくつかのヒントがあると考えています。
- このプロジェクトの一部の依存バージョンを管理するために親POMで<dependencyManagement>を定義して、特定の競合を大幅に解決できるようにしてください
- 依存するために他の人に提供されるJarパッケージである場合は、不要なJarパッケージをできるだけ渡さないようにしてください。
- mvn dependency：analyze-onlyコマンドを使用して、宣言されているが使用されていない依存関係を検出します。自分で宣言した依存関係がある場合は、それらを削除してみてください
- mvn dependency：analyze-duplicateコマンドを使用して、繰り返し定義された依存関係を分析し、繰り返し定義された依存関係をクリーンアップします
やっと
実際、巨大なプロジェクトには多くの依存関係があるはずです。しかし、依存関係がいかに複雑であっても、それを見ることを恐れないでください。いくつかの原則と注意深い分析で、すべての依存関係を追跡できます。
これらの推移的な依存関係が適切に管理されている場合、メンテナンスコストを大幅に削減できます。うまく管理できない場合、これらのワイルドチャイルドのそれぞれが次のNoSuchMethodErrorのヒューズになる可能性があります。