2017-01-17 15 views
1

これは非常に面倒です。私は、JARファイルとしてAに依存して2つのプロジェクト、プロジェクトABBを持っています。重複したバージョンの依存関係の解決

commons-beanutils:jar:1.9.2 vs. commons-beanutils:jar:1.8.0 

をそして:だからAにおける第三のライブラリXは、別のサードパーティのライブラリYに依存している、問題はMavenのは、以下のように、別のバージョンへのバージョンにプロジェクトAYを解決しますが、プロジェクトBであります下記のプロジェクトAで指定されたバージョン:プロジェクトBののpom.xmlで

net.sf.json-lib:json-lib:jar:jdk15:2.4 

は、実際の依存関係の明示的に指定されたバージョンがありません。唯一の理由AYへの依存を紹介するプロジェクトB

[INFO] +- net.sf.json-lib:json-lib:jar:jdk15:2.4:compile 
[INFO] | +- commons-beanutils:commons-beanutils:jar:1.9.2:compile 
[INFO] | +- commons-collections:commons-collections:jar:3.2.1:compile 
[INFO] | \- net.sf.ezmorph:ezmorph:jar:1.0.6:compile 

:プロジェクトA

[INFO] +- A.jar 
[INFO] | +- net.sf.json-lib:json-lib:jar:jdk15:2.4:compile 
[INFO] | | +- commons-beanutils:commons-beanutils:jar:1.8.0:compile 
[INFO] | | +- commons-collections:commons-collections:jar:3.2.1:compile 
[INFO] | | \- net.sf.ezmorph:ezmorph:jar:1.0.6:compile 

理想的なソリューションだけにプロジェクトBpom.xmlに変更を加えることです重複したバージョンの依存関係を解決してください。何か案が?ありがとう!

プロジェクトBを独自のものを導入するのではなく、A.jarから継承させることは可能ですか?

EDIT

最後に、私は働いていた何かを見つけたので、私はちょうど誰かが後で同じ問題に直面することができる場合には、ここでそれを置くと思います。 Mavenのは、単にプロジェクトAで定義されているライブラリのバージョンを使用していますが、現在のコンテキストに基づいてバージョンを動作しませんので

キーは、依存関係が除外にプロジェクトAに付属して置くことです。以下はその例です。

<dependency> 
    <groupId>com.wonderland</groupId> 
    <artifactId>project-a</artifactId> 
    <version>1.0</version> 
    <exclusions> 
     <exclusion> 
      <groupId>commons-beanutils</groupId> 
      <artifactId>commons-beanutils</artifactId> 
     </exclusion> 
     <!-- ... everything else to be excluded --> 
    <exclusions> 
</dependency> 
+0

問題は何ですか? Mavenは、POMで宣言されたバージョンを使用して競合を解決することを意図しているように動作しているようです。 – Tunaki

+0

問題は、依存関係の両方のバージョンが戦争に終わることです。2つのプロジェクトがBOMを共有して不一致を解決できることは分かっていますが、残念ながらここでは選択肢ではありません。 –

+1

どのWARですか?そしてそのPOMは何ですか? 'WEB-INF/lib'には重複はありません。 – Tunaki

答えて

1

答えに要点を入れてみましょう。

Bは戦争であり、それは

net.sf.json-lib:json-lib:jar:jdk15:2.4:compileが実際にcommons-beanutils:commons-beanutils:jar:1.8.0:compileに依存しているA.すべての推移的依存関係を継承するのでジャーA.によって異なります(私はそれを見上げました)。したがって、プロジェクトBはこの依存関係を正しく解決します(そして、それを戦争に組み込みます)。

プロジェクトAのツリーがバージョン1.9.2にコモンズ-々BeanUtilsの依存性を示します。このバージョン番号は、プロジェクトAの他の場所から来ているに違いありません。それは依存関係管理である可能性があります。バージョン1.9.2がどこから来ているのかを把握し、詳細を知る。あなたは1つの戦争で同じのgroupId /たartifactIdを持つ2つのアーティファクトを持っていることはありませんよう

は、いずれにしても、戦争は唯一のバージョン1.8.0と1.9.2ではないが含まれます。

+0

ありがとうございます。問題は、戦争には同じライブラリの2つのバージョンと複数のライブラリが含まれているということです。 –

+0

@KevinWang私はそれに対して賭けました。戦争で終わる同じgroupId/artifactIdを持つ2つのアーティファクトの詳細な例を教えてください。 –

+0

OK、私は(解凍-l B.war)あなたに1つを与える: 69409 2016年12月8日14:38 WEB-INF/libに/活性化-1.1.1.jar 62983 2017年1月17日午後05時36分WEB -INF/lib/activation-1.1.jar –

関連する問題