事實是，我們處在艱難時期。 我們花了將近三個月的時間將構建機制從Ant遷移到Maven 。 如果您打算在大型項目中做同樣的事情，那就是您必須安排的最短時間。 我們仍在努力解決這種遷移帶來的一些附帶影響，但幸運的是，它們并不是那么關鍵。

上下文

僅需要一點上下文，我們就有一個完整的Java EE 6系統，該系統由25個集成應用程序組成，每個應用程序平均具有3個模塊（EJB，WEB等），大約有80個模塊。 根據我們的Sonar分析，我們管理著接近50萬行Java代碼（不包括JS，CSS，JSP和JSF文件）。 構建所有內容需要15到20分鐘。 這取決于服務器的狀態。

決定采用Maven是開始大規模重構應用程序的先決條件，盡管使用了最新技術（Java EE 6），但多年來，這些應用程序一直遭受各種框架，設計缺陷和多種體系結構的困擾。 我們正朝著基于Java EE規范的單一架構發展，以優化依賴關系，從中長期角度降低開發成本并在Glassfish Application Server中無縫運行。

職責

由于Maven提供了靈活性，因此項目結構幾乎與Ant相同。 我們在根文件夾中有一個超級pom.xml文件，該文件基本上聲明了所有模塊，插件，附加存儲庫和依賴項。 依賴性在依賴性管理中聲明（使用標簽<dependencyManagement>）。 這樣，所有版本號都在一個地方聲明。 除了超級pom.xml之外，我們還為每個集成應用程序提供一個文件夾，并且在每個文件夾中都有一個應用程序pom.xml和其他三個文件夾，每個Java EE模塊（EAR，EJB，WEB）都有一個文件夾。 應用程序的pom.xml繼承自超級pom，它基本上聲明了組成應用程序的模塊。 在模塊文件夾中，我們還有一層pom文件。 這些pom文件繼承自各自應用程序的pom文件，并描述其模塊的特殊性。 總之，從系統整體到Java EE模塊，我們共有三個pom文件級別。

結構示例類似于我們正在使用的結構。

出于開發目的，我們避免在本地部署整個應用程序。 這就是為什么我們在每個應用程序中都有一個EAR模塊的原因。 這樣，我們節省了僅部署正在處理的應用程序的時間。 打包以部署在服務器上時，不考慮那些應用程序EAR模塊。 為了為服務器構建完整的EAR，我們有一個特殊的應用程序，其中包含EAR模塊，該模塊的pom文件將所有EJB和WEB模塊聲明為依賴項。 執行目標
這個pom.xml上的包實際上將創建超級EAR文件。

EAR模塊將整個系統打包在一個部署文件中。

善良

在實施Maven之后評估項目，我們可以注意到以下好處：

Maven為簡化構建背后的邏輯做出了貢獻 ：現在，每個人都知道發生了什么，因為pom.xml文件比build.xml文件更容易理解。 我們的Ant文件是由
Netbeans ，因此非常大且不可讀。 實際上，我們很幸運能夠讓它們工作這么長時間，因為很難對其進行維護。 毫無疑問，我們很快就會發現無可挽回的混亂。

Maven還有助于使所有項目相關性井井有條 ：我們從一個約100 MB的EAR軟件包變成了一個約50MB的EAR軟件包，減少了50％。 它有助于縮短部署時間。

我們有機會對項目進行了清理 ：在收集依賴關系以編寫pom.xml文件時，我們發現不再需要某些模塊。 通過模塊傳播的庫也被刪除，以支持Maven的依賴關系管理。 總而言之，我們一直說“ Maven是一場噩夢”，直到我們最終一切都井井有條，然后我們變得更加快樂和放松。 那也是大多數人所說的，因為要為特定情況找到解決方案并不容易，而且每個人都有特定的情況要處理。

簡短的學習曲線 ：部署Maven之后，我們拜訪了所有開發人員，重新配置了Netbeans以識別Maven項目，并向他們解釋了從那時起如何進行。 他們所有人都可以立即繼續他們的開發活動，并且只觸發了一些支持請求。 這些電話都沒有阻塞問題。 我不得不說，Netbeans為減少學習難度做出了很大的貢獻，因為所有必需的目標都是直接從IDE執行的，并且不需要轉到命令行，就像通常在Eclipse中發生的那樣。

壞人

不幸的是，我們遇到了一些挫折：

現在，使用Maven進行構建需要更長的時間 ：由于這個原因，我們注意到開發人員的生產力下降了，最終使我們有些沮喪。 由于我們不會回滾到Ant，因此我們正在考慮JRebel對更改的代碼進行動態重載，以補償我們花費的額外時間。

我們正在使用某些在Maven中央存儲庫或其他地方找不到的庫 ：有些是商業庫，有些則太舊了。 我們還發現可用的庫存在不一致之處，在運行時會引發許多異常（即Apache FOP）。 對于這些情況中的每一種，我們都必須找到不太理想的解決方法，但我們不能這么長時間保持這種狀態。 我們必須安裝本地Nexus存儲庫以解決特殊情況。 這在我們的清單中。

發生意外行為 ：盡最大的努力不足以避免應用程序中的意外行為。 我們建立了一個電子表格，列出了所有應用程序及其各自的模塊。 記錄所有庫和模塊之間的依賴關系； 描繪了項目結構； 深入細節。 為了詳細說明此電子表格，我們花了幾天的時間研究系統的內幕，吸收低級機制和設計決策。 所有收集的信息都用于遷移。 但是，依賴關系的重新排列以及重復項和未使用庫的刪除導致導航流中斷，警報消息無處發出，URL路徑更改以及許多其他意外事件。 不幸的是，我們無法預測這些問題，并且我們花費在修復上的時間比最初預計的要多得多。

結論

最后，我想為那些計劃在中/大型項目中采用Maven的人士提供一些建議：

與最終用戶交流遷移：與最終用戶交流未來幾天將發生的事情非常重要。 用戶應注意，由于他們有責任改善自己的業務，因此我們也有義務改善自己的業務。 這意味著新功能的交付將暫時放慢速度，從而為更快發布更好的產品鋪平道路。 如果他們不知道發生了什么，那么他們對問題的容忍度就會非常低，從而損害項目的聲譽。

即使運行良好，也不要害怕更改 ：我們已經問過自己：如果Ant運行良好，為什么要遷移到Maven。 實際上，我們的策略是降低復雜性以簡化問題的解決。 因此，我們不害怕遷移，因為預防措施也非常重要。

將整個遷移置于版本控制下，以幫助調查問題 ：一旦創建了所有pom文件并進行了版本控制，則應分別提交這些文件中的每個小更改，以便在出現意外問題時恢復更改。 它有助于找出原因。 很高興知道Ant和Maven文件之間沒有沖突。 因此，兩者都可以在遷移期間留在同一個分支中，而對開發人員沒有任何影響。

如果沒有像Maven這樣的構建系統，就不要進行大規模的重構 ：成功的重構取決于對應用程序的詳細了解，采用Maven會促使您進行廣泛的研究。 除此之外，該項目將變得更加干凈，組織得更好。

Maven還有其他替代方法，例如Apache Ivy和Gradle ，但是，盡管應受到批評，但由于其成熟度，我們仍然推薦在替換Ant時使用Maven。 豐富的插件產品組合； 網絡上的大量文檔； 和豐富的IDE支持。 但是，一旦Maven到位，最好評估其他替代方案。 最初的海嘯過后，其他海浪將悄悄襲來。

參考： Hildeberto博客博客中的JCG合作伙伴 Hildeberto Mendonca 將大型項目從Ant遷移到Maven 。

翻譯自: https://www.javacodegeeks.com/2012/12/migrating-a-large-project-from-ant-to-maven.html

總結

以上是生活随笔為你收集整理的将大型项目从Ant迁移到Maven的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。