什麼是更新多模塊Maven項目模塊版本的最佳stategy

Question

考慮：多模塊Maven項目

任務：更新版本後，每個版本

我看到兩種不同的策略：

策略1 - 整個更新：儘管所有模塊的更新版本，在那裏更新或不

策略2 - 簡約更新：只更新版本那些實際上影響

模塊，假設我們有以下項目結構：

root 
---dao 
---domain 
---web 
    ---site1 
    ---site2 
---processors 
    ---processor1 
     ---processor1Service 
     ---processor1Util 
     ---processor1Tests 
    ---processor2 
     ---processor2Service 
     ---processor2Util 
     ---processor2Tests 
---simulators 
    ---simulator1 
     ---simulator1Service 
     ---simulator1Util 
     ---simulator1Tests 
    ---simulator2 
     ---simulator2Service 
     ---simulator2Util 
     ---simulator2Tests 
---etc 

所有父POM具有包裝類型 - 聚甲醛。所有最終模塊都具有資源生成類型 - jar，war，sar等。 根pom包含dependencyManagement其中列出所有子模塊的部分。

---

策略1：

• 發佈經理RM（或任何人）合併從 '功能' 分支（S）
• 所有的持續集成的東西正在發生的更新（讓他們沒事）
• RM調用mvn版本：versionUpdate -DsetVersion = 1。2根
• 做

策略2：

• RM合併從 '功能' 分支（S）

• 所有的持續集成的東西正在發生的更新（讓他們OK）

• RM檢查使用顛覆工具（git，svn，whatever）實際受到影響的模塊
• RM遞增受影響的模塊的版本手動
• 完成

---

策略1：

益：

1. 來自人沒有手動輸入（除版本號碼也許）
2. POM配置是微不足道的並且均勻地，可僅在根POM使用dependencyManagement部
3. 所有模塊作爲結果的單個版本不存在 模塊版本
4. 無需依賴於外部工具動物園處理該必須檢查 實際更新的位置（甚至更糟糕 - 取決於RM注意力）
5. 開發人員不限制他們的模塊進行任何與 無關的更改（fe沒必要害怕，如果你添加新行或 意外地運行在IDE自動格式化工具）

缺點：

1. 將被更新的實際上不是模塊的版本 影響 - 結果可能有問題的硬盤空間

策略2：

個好處：

1. 將被更新，實際已更新

缺點模塊的版本：

1. 動物園的版本。 dao_1.2取決於domain_1.52，都取決於 etc_1。639模塊
2. 手動輸入
3. 從外部工具的依賴是必須檢查更新，實際

請分享你的意見。如何在大型項目中處理此問題，例如springframework

Answer 1

就我個人而言，我會絕對採取您的策略1.這是在我工作的公司中使用的戰略。您提到的不需要升級的HDD空間或升級模塊版本的副作用與「版本動物園」相比是次要問題。

只有在您使用OSGI架構並且這需要非常精確的模塊版本控制策略的情況下，我纔會爲您的策略2進行投票，並且如果一次升級所有版本，它將毀掉OSGI的巨大利益 - 僅部署需要更新的模塊/子模塊）。

我也建議你會對http://java.dzone.com/articles/why-i-never-use-maven-release看看這給很好的提示如何在多模塊Maven項目的升級版本，以及如何在任何CVS