使用maven2一段時(shí)間了，我基本把我自己能夠遷移的project都轉(zhuǎn)換為maven2 project，以下是我的一點(diǎn)感想。

（原作者溫少，轉(zhuǎn)載請(qǐng)注明）

亂世盼英雄

現(xiàn)在的軟件開發(fā)，比過(guò)去的軟件開發(fā)要復(fù)雜得多。包括在參與開發(fā)的人數(shù)、代碼規(guī)模、復(fù)雜的需求、依賴包的復(fù)雜性、使用到更多的技術(shù)、多個(gè)項(xiàng)目之間的復(fù)雜依賴關(guān)系。

現(xiàn)在的開發(fā)人員，要掌握的技術(shù)要比過(guò)去的開發(fā)人員要多，不是現(xiàn)在的開發(fā)人員比以前的開發(fā)人員本身更優(yōu)秀，而是擁有更多的資料、更多的學(xué)習(xí)機(jī)會(huì)、更多更大規(guī)模的時(shí)間，同時(shí)軟件行業(yè)也在發(fā)展。說(shuō)一句題外話，老程序員，如果不與時(shí)俱進(jìn)，靠老本，是無(wú)法和新一代程序員競(jìng)爭(zhēng)的，當(dāng)然，老程序員，擁有更多的經(jīng)驗(yàn)，掌握新技術(shù)的速度更快，這又是另外一回事。

開發(fā)人員掌握的技術(shù)更復(fù)雜了，項(xiàng)目用得的技術(shù)自然也是更復(fù)雜，例如一個(gè)web項(xiàng)目，可能使用到很多技術(shù)，面向?qū)ο蟆⒎盒汀r-mapping、依賴注入（spring-framework）、全文檢索（lucene）、數(shù)據(jù)庫(kù)、集群、工作流、web service等等。

由于使用了多種技術(shù)，這些技術(shù)可能是JDK提供的，也可能是第三方開源組織提供的，或者不同的商業(yè)公司提供的。

于是出現(xiàn)了一個(gè)新的難題，就是包依賴復(fù)雜性。以前，你很難想象你的代碼依賴數(shù)十個(gè)不同開源組織、商業(yè)公司提供的庫(kù)。例如，我們經(jīng)常使用的log4j、junit、easymock、ibatis、springframework，每個(gè)組件都有悠久的歷史，存在不同的版本，他們之間版本還有依賴關(guān)系。

項(xiàng)目依賴的復(fù)雜性，經(jīng)常的，一個(gè)較大部門有10-30個(gè)項(xiàng)目是常事，項(xiàng)目之間有不同版本的依賴關(guān)系，部門與部門之間的項(xiàng)目也存在復(fù)雜的版本依賴關(guān)系。

Eclipse本身提供Project的依賴，但是簡(jiǎn)單的依賴顯然解決不了問(wèn)題。例如Project B依賴Project A，Project A依賴第三方的jar包abc-1.0.jar，那么需要在兩個(gè)項(xiàng)目的lib下都存放abc-1.0.jar，這產(chǎn)生冗余，當(dāng)Project數(shù)量多起來(lái)，這個(gè)冗余就產(chǎn)生了管理問(wèn)題，如果需要將abc-1.0.jar升級(jí)為abc-1.1.jar，則需要在兩個(gè)Project中同時(shí)修改，如果Project數(shù)量達(dá)到10個(gè)以上，而且是不同項(xiàng)目組維護(hù)的項(xiàng)目，這個(gè)就是非常麻煩的事情。而且Project A修改依賴，為啥需要Project B也作相應(yīng)的修改呢？

需要解決此問(wèn)題，就需要在Project A的包中描述其依賴庫(kù)的信息，例如在META-INFO記錄所以來(lái)的abc-1.0.jar等。Eclipse的plug-in擁有類似的方案，但是這樣一來(lái)，就使得開發(fā)Project B的項(xiàng)目組，需要把Project A的代碼從源代碼庫(kù)中check out出來(lái)。在依賴鏈末端的項(xiàng)目組是很慘的。

由于Project數(shù)量眾多，關(guān)系復(fù)雜，dailybuild的ant腳本編寫成了很麻煩的事情，使用Project依賴的方式，更加使得編寫dailybuild ant script是非常痛苦的事情。

當(dāng)然也可以不使用project依賴的方式，而使用artifact lib的依賴方式，但是artifact lib的依賴方式，就是同時(shí)修改多個(gè)project，互相調(diào)試時(shí)帶來(lái)了痛苦。

在以前，我們面臨這些問(wèn)題時(shí)，唯一的感覺就是，這事情TMD的太麻煩，幾乎是失控了。

maven的出現(xiàn)，解決這種問(wèn)題看到了希望。maven出現(xiàn)的原因就是，現(xiàn)在的開發(fā)管理復(fù)雜度達(dá)到了一定程序，需要專門的開發(fā)管理工具，這樣的工具需要涵蓋開發(fā)的各個(gè)階段，包括工程建立、配置依賴管理、編譯、測(cè)試、產(chǎn)生分析報(bào)告、部署、產(chǎn)生制品等階段。目前，各個(gè)階段的工具都存在，但是不是集成的，對(duì)使用帶來(lái)了很大麻煩。maven集成了這些工具，提高了統(tǒng)一的環(huán)境，使得使用更簡(jiǎn)單。

現(xiàn)在maven非常流行了，apache上所有java project都已經(jīng)build by maven，其他跟進(jìn)的開源項(xiàng)目非常多，例如mule、hibernat等等，商業(yè)公司也很多在采用，sun公司提供有maven2 repository。

現(xiàn)在，2007年，如果你還沒采用maven project，你可能需要思考一下，是否你使用了不恰當(dāng)?shù)姆绞焦芾淼拇a，或者你落伍了？

maven的一些常用任務(wù)

compile 編譯代碼
test 運(yùn)行單元測(cè)試
package 打包代碼
site 產(chǎn)生報(bào)告，例如java doc、junit的通過(guò)率報(bào)告和覆蓋率報(bào)告、findbugs的分析報(bào)告等等。
assembly 使用需求產(chǎn)生assembly，例如把生成一個(gè)程序目錄，包括bin、config、lib、logs，把依賴包放在lib中。
deploy 部署制品到repository中。

這些都是常用的任務(wù)，在以前編寫腳本很麻煩，現(xiàn)在在maven中，一切都是很簡(jiǎn)單，需要仔細(xì)設(shè)置時(shí)功能又強(qiáng)大到令人驚嘆，例如site的fml，assembly。

maven資源庫(kù)

maven官方提供了一個(gè)常用lib的資源庫(kù)，包括apache的所有java項(xiàng)目，開源常用的基本都能夠找到，例如mule、c3p0、easymock、hibernate、springframework、json等等，版本齊全，任你挑選。

可以部署本地資源庫(kù)代理提高下載速度。使用maven proxy。

maven體系結(jié)構(gòu)

maven使用plug-in的體系，使用很好的自動(dòng)更新策略，本身用到的jar都是lazy download的，可以指定download的repository。這樣，初始下載的maven是一個(gè)很小的程序，使用的時(shí)候從本地的資源庫(kù)或者本地代理資源庫(kù)高速下載lib。maven的插件體系，充分利用了internet的資源豐富和局域網(wǎng)的高速帶寬，使用本地repository時(shí)，可以享受到每秒鐘數(shù)M的下載速度，感覺就是，人生真是美妙！

elcipse的plug-in體系，就不是那么好用了，我們使用eclipse的find and install功能下載或者更新插件時(shí)，慢如蝸牛，依賴缺失時(shí)的煩惱，更新一個(gè)plug-in，可能耗費(fèi)你數(shù)個(gè)小時(shí)，第三方的plug-in的下載服務(wù)器可能更慢，例如subversive的plugin-in，有一次我花了兩天還沒下載好，只好使用下載工具下載好，copy到plug-in目錄下。此時(shí)，我們總是感嘆，人生總是有很多煩惱事啊！

相比之下，高下立判！在此我不是說(shuō)eclipse的plug-in體系結(jié)構(gòu)設(shè)計(jì)不好，eclipse的插件體系非常優(yōu)秀，但是還有很大改進(jìn)空間！