事實是，我們處在艱難時期。 我們花了將近三個月的時間將構(gòu)建機(jī)制從Ant遷移到Maven 。 如果您打算在大型項目中做同樣的事情，那就是您必須安排的最短時間。 我們?nèi)栽谂鉀Q這種遷移帶來的一些附帶影響，但幸運(yùn)的是，它們并不是那么關(guān)鍵。

上下文

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

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

職責(zé)

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

結(jié)構(gòu)示例類似于我們正在使用的結(jié)構(gòu)。

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

EAR模塊將整個系統(tǒng)打包在一個部署文件中。

善良

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

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

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

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

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

壞人

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

現(xiàn)在，使用Maven進(jìn)行構(gòu)建需要更長的時間 ：由于這個原因，我們注意到開發(fā)人員的生產(chǎn)力下降了，最終使我們有些沮喪。 由于我們不會回滾到Ant，因此我們正在考慮JRebel對更改的代碼進(jìn)行動態(tài)重載，以補(bǔ)償我們花費(fèi)的額外時間。

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

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

結(jié)論

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

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

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

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

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

Maven還有其他替代方法，例如Apache Ivy和Gradle ，但是，盡管應(yīng)受到批評，但由于其成熟度，我們?nèi)匀煌扑]在替換Ant時使用Maven。 豐富的插件產(chǎn)品組合； 網(wǎng)絡(luò)上的大量文檔； 和豐富的IDE支持。 但是，一旦Maven到位，最好評估其他替代方案。 最初的海嘯過后，其他海浪將悄悄襲來。

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。