maven解決包衝突方法

默認版本比較定義

默認規範應組成以下：

<major>.<minor>.<revision>([ -<qualififer> ] | [ -<build> ])

這裏：

• qualififer - 限定詞部分是可選的（而且是SNAPSHOT，alpha-1，alpha-2）
• build 部分是可選的（若是指定，則從1開始遞增）
• 任何「 0」構建或修訂元素均可以省略。
• 只能給出 build 和 qualifier 中的一個（請注意，帶有時間戳的限定符包括一個 build 號，但這並不相同）

對於排序，將依次進行如下操做，直到找到不相等的元素：

• 主要版本的數值比較
• 次要版本的數值比較
• 若是不存在修訂，則添加「 .0」以進行比較
• 修訂的數值比較
• 若是不存在限定符，則比限定符更新

• 限定詞不區分大小寫的字符串比較

  • 這樣能夠確保時間戳正確排序，而且SNAPSHOT比等效時間戳更新
  • 這也能夠確保beta緊跟alpha以後，就像rc同樣
• 若是沒有限定符，而且構建不存在，請添加「 -0」以進行比較
• 構建的數值比較

Maven根據最近勝利策略（nearest wins strategy）的原則工做，同時解決依賴衝突，這意味着它在依賴樹中找到更接近的版本，它將採用該版本並忽略其餘版本。實際上Maven有點懶，因此每當它開始尋找依賴時，它就會從根目錄開始遍歷樹，不管它先前找到哪一個版本，它都會選擇它並從它們返回而不進一步。若是它進一步尋找依賴版本，可能會有機找到一些更新的版本，但它從第一個發現的版本那裏返回，並採用舊版本並用它來解決依賴關係。

能夠用下面的命令顯示依賴樹：

mvn dependency:tree

老實說，這不是maven的錯，由於它想盡快完成這項工做。最重要的是，maven 不知道你的應用程序指望哪一個版本，因此Maven會告訴你，嘿，你有責任讓我知道你想要哪一個版本，若是你不告訴我，我會以本身的方式工做，即更近更好。

請下載本文的github源代碼：

https://github.com/yujiaao/maven-dependency-conflict-demo

咱們有一個 web 應用 resolve-web，該工程依賴於 project-A 和project-B，project-A 依賴於 project-common 的 1.0 版本並調用其中的 sayHello() 方法。project-B 依賴於project-C，而project-C又進一步依賴於project-common的2.0 版本並調用其中的 sayGoodBye() 方法。project-common 的 1.0 和 2.0 版本是不一樣的，1.0 中之包含sayHello() 方法，而2.0 中包含了sayHello()和sayGoodBye()兩個方法。整個項目的依賴關係以下圖：

根據Maven的transitive依賴機制，resolve-web 將同時依賴於project-common 的 1.0 和 2.0 版本，這就形成了依賴衝突。而根據最近獲勝策略，Maven 將選擇 project-common 的 1.0 版本做爲最終的依賴。

這和 Gradle 不一樣，Gradle 在默認狀況下將選擇最新的版本做爲獲勝版本。

而對於Maven，因爲proejct-common的1.0版本比2.0版本在依賴樹中離resolve-web更近，故 1.0 版本獲勝。在 resolve-web 中執行mvn dependency:tree -Dverbose 能夠看到 resolve-web 的依賴關係：

[INFO] resolve-web:resolve-web:war:1.0-SNAPSHOT
[INFO] +- junit:junit:jar:3.8.1:test
[INFO] +- project-B:project-B:jar:1.0:compile
[INFO] |  \- project-C:project-C:jar:1.0:compile
[INFO] |     \- (project-common:project-commmon:jar:2.0:compile - omitted for conflict with 1.0)
[INFO] +- project-A:project-A:jar:1.0:compile
[INFO] |  \- project-common:project-commmon:jar:1.0:compile
[INFO] \- javax.servlet:servlet-api:jar:2.4:provided