現象
Mavenプロジェクト、春・コンテキストパッケージの導入を作成します。
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>5.0.8.RELEASE</version>
</dependency>左側にこの時点ルックのlibで、我々は、この現象はつまり、依存のjarパッケージの現在の座標は、バージョンの導入に付いてくる、推移的依存関係と呼ばれる座標、より多くのjarパッケージの導入がここにあることを見つけますの5.0.8。
次に、我々はspringmvcをご紹介します。私たちは、バージョン4.2.4導入バージョンを変更します
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-webmvc</artifactId>
<version>4.2.4.RELEASE</version>
</dependency>私たちは、アイデアMavenの解析図、MVCとコンテキストに透けて見えるとSPRNGコアに依存することができ、それはバージョン4.2.4が依存している、バージョン5.0.8に依存しています。
だから、どのバージョンでは、それをロードする場合はtrueです。これは、バージョン5.0.8です。
この時点で、競合のjarパッケージがあるということです、そして、我々はこの問題を解決するため、3つの方法があります。
免責優先の原則
5.0.8当社POMファイルが最初に宣言されているこの時点では、文の4.2.4バージョンでは、我々は順序が逆になります。
我々は彼らの共通依存のjarパッケージを見つけるこの時点で、これは第一原理計算書で、4.2.4バージョンとなっています。
近く優先の原則
例えば、我々は順序を逆にしたくない、私たちは春・コアの4.2.4バージョンを使用したいです。私たちは、一人で来て導入することができます。
再びこの時、私たちは、4.2.4バージョンとなっているのスプリングコアに依存していることがわかります。
第一の原則は、最も近い、近くの優先順位は、依存伝送の優先度より直接依存し、直接依存優先事項です。
依存を排除
このように、我々は、ばねコンテキストの直接依存負のスプリングコアを渡すことができます。
依存性を見て、この時間は4.2.4に変更されました。
その内部バージョン番号を書き込まないときラベルの除外を使用し、これはバージョン番号を記入していない唯一のケースです。彼は現在のデフォルト依存バージョンに行ってきましたので。