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

（原作者溫少，轉載請注明）

亂世盼英雄

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

現在的開發人員，要掌握的技術要比過去的開發人員要多，不是現在的開發人員比以前的開發人員本身更優秀，而是擁有更多的資料、更多的學習機會、更多更大規模的時間，同時軟件行業也在發展。說一句題外話，老程序員，如果不與時俱進，靠老本，是無法和新一代程序員競爭的，當然，老程序員，擁有更多的經驗，掌握新技術的速度更快，這又是另外一回事。

開發人員掌握的技術更復雜了，項目用得的技術自然也是更復雜，例如一個web項目，可能使用到很多技術，面向對象、泛型、or-mapping、依賴注入（spring-framework）、全文檢索（lucene）、數據庫、集群、工作流、web service等等。

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

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

項目依賴的復雜性，經常的，一個較大部門有10-30個項目是常事，項目之間有不同版本的依賴關系，部門與部門之間的項目也存在復雜的版本依賴關系。

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

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

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

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

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

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

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

現在，2007年，如果你還沒采用maven project，你可能需要思考一下，是否你使用了不恰當的方式管理的代碼，或者你落伍了？

maven的一些常用任務

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

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

maven資源庫

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

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

maven體系結構

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

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

相比之下，高下立判！在此我不是說eclipse的plug-in體系結構設計不好，eclipse的插件體系非常優秀，但是還有很大改進空間！