これは、mvn -o dependency:tree -Dverbose -Dincludes=log4j
を使用してMaven 2.2.1によって生成された依存関係ツリーです。
[INFO] [dependency:tree {execution: default-cli}]
[INFO] com.openboxes.renderingservice:common:jar:1.0
[INFO] +- org.springframework:spring:jar:2.0.4:compile
[INFO] | \- commons-logging:commons-logging:jar:1.1:compile
[INFO] | \- log4j:log4j:jar:1.2.12:compile
[INFO] \- it.mycompany.portal:server:jar:1.5-SNAPSHOT:compile
[INFO] \- org.slf4j:slf4j-log4j12:jar:1.1.0:compile
[INFO] \- (log4j:log4j:jar:1.2.13:compile - omitted for conflict with 1.2.12)
ご覧のとおり、log4j v1.2.12はv1.2.13よりも優先されます。
「Mavenはバージョンの競合を最も近い勝利の戦略と解決します」( http://maven.Apache.org/plugins/maven-dependency-plugin/examples/resolving-conflicts-using-the-dependencyを参照) -tree.html )ですが、これらの2つの依存関係は同じ距離にあるようです(2つのネストレベル、私は間違っているのでしょうか?)。
誰かがこの結果を説明できますか?
はい、log4jはこのPOMで明示的に宣言されていませんが(そうすべきであると思います)、Mavenの動作をよりよく理解したいと思います。
THX
私は http://maven.Apache.org/guides/introduction/introduction-to-dependency-mechanism.html で自分自身で答えを見つけました==:「2つの依存バージョンが同じ深さの場合依存関係ツリーでは、Maven 2.0.8まではどちらが勝つかは定義されていませんでしたが、Maven 2.0.9以降では、宣言の順序が重要になります。最初の宣言が勝ちます。」.
それは私にとって非常に疑わしい戦略のようです。 :-\
2つの依存関係バージョンが依存関係ツリー内で同じ深さである場合、または同じ深さでない場合、プロジェクトへの閉鎖がプロジェクトにポイントされます。
依存関係の深さがわかったら、それを解決する2つのソリューションがあります。
First:これらの依存関係がライブラリ内の別のプロジェクトの一部として含まれている場合は、手動で削除できますが、プロジェクトにその依存関係を指定したくないのは、自分に最も近いためです。事業。以下に示すように、プロジェクトpom.xmlで特定のプロジェクトのjarを除外できます。
<dependency>
<groupId>org.cassandraunit</groupId>
<artifactId>cassandra-unit</artifactId>
<version>3.1.3.2</version>
<exclusions>
<exclusion>
<groupId>org.Apache.commons</groupId>
<artifactId>commons-lang3</artifactId>
</exclusion>
</exclusions>
</dependency>
2番目:期待するバージョンのjarをプロジェクトのpom.xmlに直接追加します。次に、それはプロジェクトに最も近いjarになります。
上記の両方の方法を使用すると、問題を解決できます。