2017-09-21 76 views
1

我正在研究一個大的Java代碼庫,它被分成多個模塊,每個模塊都有一個單獨的pom.xml,所有模塊都由頂級pom.xml管理。如何在跨多個pom的Maven項目上設置傳遞依賴項版本

我目前正在引入一些庫依賴項。可傳遞的依賴關係集很大,幸運的是,對於不同的模塊,依賴關係版本存在衝突。

這裏是我的情況的簡化:

project/pom.xml 
     /module-a/pom.xml # references library-a, depends on library-c:v1 
     /module-b/pom.xml # references library-b, depends on library-c:v2 
     /module-c/pom.xml # references module-a and module-b 

現在爲module-a單元測試將行使library-alibrary-c:v1存在,而module-b將在library-c:v2存在行使library-b

麻煩的是,module-amodule-b需要在當module-c部署在同一個類路徑生活在一起,但無論選擇何種的library-c版本時module-c包裝,圖書館中的至少一個組合尚未單元測試!

我想以某種方式將library-c的版本固定在父級別的級別上,而不是在每個模塊中重複自己,這些模塊在傳遞上取決於library-c;理想情況下,它會以這種方式添加,表明它是傳遞依賴關係,如果library-alibrary-b不再依賴它,則允許消失。

我希望保證每個傳遞依賴關係都有一個版本選擇爲 ,因爲這個父項目包含了整個項目的根源,如果這不是真的,我希望這個構建可以炸燬。我編寫了一個工具來分析mvn dependency:tree的輸出(將樹的葉片變成從葉片到根的路徑森林,然後用依賴路徑查找葉片的所有不同版本),以便我可以看到問題,但沒有明確解決對每一次衝突的傳遞依賴,以及使用多餘的聲明來膨脹poms,這似乎並不富有成效。這是我會做的,如果我沒有選擇,自然。

用Maven處理這個傳遞依賴衝突問題的最好方法是什麼?

這個問題有多嚴重?除了獲得難以令人信服的測試覆蓋率之外,在實踐中,我發現在運行時由於部署錯誤的版本而導致JVM殺死NoSuchMethodError。我希望至少在測試時間看到這些。

回答

1

看起來像有兩個方面是:

  1. 你需要堅持的依賴的單一版本,無論是顯式聲明的或過渡地獲得

你可以在這裏使用<dependencyManagement/>。例如在頂級的pom中。XML可以釘住的library-c版本:

<dependencyManagement> 
<dependencies> 
    <dependency> 
     <groupId>your.group.id</groupId> 
     <artifactId>library-c</artifactId> 
     <version>2</version> 
    <dependency> 
    <dependencies> 
<dependencyManagement> 

然後在library-alibrary-b你將宣佈在library-c的依賴性如下:

<dependencies> 
    <dependency> 
    <groupId>your.group.id</groupId> 
    <artifactId>library-c</artifactId> 
    <dependency> 
<dependencies> 

通過在父母的dependencyManagement你堅持聲稱這種依賴性在這兩個子模塊上使用父級中聲明的版本。

  • 你想保護自己在未來
  • 發生的不愉快的依賴性增加,您可以使用這裏的Maven Enforcer plugin,特別是dependencyConvergence規則。例如:

    <plugin> 
        <groupId>org.apache.maven.plugins</groupId> 
        <artifactId>maven-enforcer-plugin</artifactId> 
        <version>3.0.0-M1</version> 
        <executions> 
         <execution> 
         <id>enforce</id> 
         <configuration> 
          <rules> 
          <dependencyConvergence/> 
          </rules> 
         </configuration> 
         <goals> 
          <goal>enforce</goal> 
         </goals> 
         </execution> 
        </executions> 
    </plugin> 
    

    如果執行程序發現非收斂依賴性,則可以將其配置爲發生故障或發出警告。

    +0

    我已經在使用'dependencyManagement' - 實際上我編寫了另一個工具來將所有版本元素從子項目中的依賴項移動到父項目管理部分中的依賴項元素中。爲了解決這個問題,我目前在306個傳遞依賴關係中有20個衝突版本。根據你的估算,我需要爲孩子添加20 * x(至少x> 2)顯式依賴部分。聽起來像是另一種工具的工作。 –

    +0

    噢,另一個有趣的factoid - 總共有3519個不同的依賴關係路徑: –

    +0

    聽起來就像你需要一個'dependencyManagement'組合來定義並堅持版本和'enforcer'來告訴你問題出在哪裏(例如使用'fail = false'運行執行者的'dependencyConvergence'規則將會發出一個非常類似於工具生成的報告:「將樹的葉子變成從葉子到根的路徑森林,然後查找所有具有依賴路徑的不同版本的葉子「)。但是,沒有什麼神奇的咒語來創建你的'dependencyManagement',因此給出了你有一些腳本期待的3519個依賴路徑。祝你好運 :) – glytching

    相關問題