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

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

亂世盼英雄

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

maven資源庫

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

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

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

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

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

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