第一章 Maven簡介

###1.1 何爲Maven###  Maven的中文意思是「專家」、「內行」。做爲Apache組織的一個頗爲成功的開源項目，Maven主要服務於基於Java平臺的項目構建，依賴管理和項目信息管理。 #### 1.1.1 什麼是構建####  軟件開發過程當中編寫源代碼以外的編譯、運行單元測試、生成文檔、打包和部署就是構建。若是手工完成這一系列的操做那成本過高了，因而有人用軟件的方法讓一系列的工做徹底自動化，使得構建的工做能夠像自動化流水線同樣只須要一條簡單的命令。 #### 1.1.2 Maven是一個優秀的構建工具####  Maven做爲一個構建工具，不只能幫咱們自動化構建，還可以抽象構建過程，提供構建任務實現；它跨平臺，提供對外一致的操做接口，這一切足以使它成爲優秀的流行的構建工具。 #### 1.1.3 Maven不只僅是構建工具####  Maven不只是構建工具，仍是一個依賴管理工具和項目信息管理工具。它提供了中央倉庫，可以自動下載構建。

###1.2. 爲何須要Maven### #### 1.2.1 組裝PC和品牌PC####  使用腳本構建高度自定義的構建系統就像組裝PC，耗時費力結果也不必定好。使用Maven就像購買品牌PC，省時省力，並能獲得成熟的構建系統，Maven仍是開源的可以獲得Maven社區的幫助。 #### 1.2.2 IDE不是萬能的####  咱們應該合理的使用IDE而不是過多的依賴它。使用IDE構建須要一次次的點擊鼠標，手動操做意味着效率低和容易出錯。Maven是這方面的專家，並且主流的IDE都集成了Maven，咱們能夠在IDE中使用Maven方便的執行構建。 #### 1.2.3 Make####  Make也許是最先的構建工具，它由Stuart Feldman於1977年在Bell實驗室建立。目前Make有不少衍生版本，包括流行的GUN Make和BSD Make以及Windows平臺的Microsoft nmake等。
 Make由一個名爲Makefile的腳本文件驅動，該文件使用Make自定義的語言格式。其基本組成規則爲一些列規格(rules)，而每一條規格又包括目標、依賴和命令。
 Make經過一系列目標和依賴將整個構建過程串聯起來，同時利用本地命令完成每一個目標的實際行爲。Make的強大之處在於它能夠全部系統的本地命令。可是，Make將本身和操做系統綁定在一塊兒了，也就是說Make就不能實現（至少很難）跨平臺的構建，這對於Java來講是很不友好的。此外，Makefile的語法也成爲問題，不少人抱怨Make構建失敗的緣由每每就是一個難以發現的空格或者Tab使用錯誤。 #### 1.2.4 Ant####  它最先用來構建著名的Tomcat，建立它的動機就是受不了Makefile的語法格式。能夠將Ant看做是一個Java版本的Ant，正由於使用了Java，Ant是跨平臺的。此外，Ant用XML定義構建腳本，更加友好。
 和Make同樣Ant也是過程式的，開發者顯示的制定一個目標以及完成此目標所須要執行的任務。針對每個項目，開發者都須要從新編寫這一過程，這裏包含着很大的重複。Ant是沒有依賴管理的，因此很長一段時間內Ant都不得不手工管理依賴。 #### 1.2.5 不重複發明輪子####  小張是一家小型民營軟件公司的程序員，他所在的公司要開發一個新的Web項目。通過協商，決定使用Spring、iBatis和Tapstry。jar包去哪裏找呢？公司裏估計沒有人能把Spring、iBatis和Tapstry所使用的jar包一個很多地找出來。你們的作法是，先到Spring的站點上去找一個spring.with.dependencies，而後去iBatis的網站上把全部列出來的jar包下載下來，對Tapstry、Apache commons等執行一樣的操做。項目尚未開始，WEB.INF/lib下已經有近百個jar包了，帶版本號的、不帶版本號的、有用的、沒用的、相沖突的，怎一個「亂」字了得！
 在項目開發過程當中，小張不時地發現版本錯誤和版本衝突問題，他只能硬着頭皮逐一解決。項目開發到一半，經理髮現最終部署的應用的體積實在太大了，要求小張去掉一些沒用的jar包，因而小張只能加班加點地一個個刪……
 小張隱隱地以爲這些依賴須要一個框架或者系統來進行管理。
 小張喜歡學習流行的技術，前幾年Ant十分流行，他學了，併成爲了公司這方面的專家。小張知道，Ant打包，無非就是建立目錄，複製文件，編譯源代碼，使用一堆任務，如copydir、fileset、classpath、ref、target，而後再jar、zip、war，打包就成功了。
 項目經理髮話了：「兄弟們，新項目來了，小張，你來寫Ant腳本！」
 「是，保證完成任務！」接着，小張繼續建立一個新的XML文件。targetclean; target compile; target jar; …… 不知道他是否想過，在他寫的這麼多的Ant腳本中，有多少是重複勞動，有多少代碼會在一個又一個項目中重現。既然都差很少，有些甚至徹底相同，爲何每次都要從新編寫？
 終於有一天，小張意識到了這個問題，想複用Ant腳本，因而在開會時他說：「之後就都用我這個規範的Ant腳本吧，新的項目只要遵循我定義的目錄結構就能夠了。」經理聽後以爲頗有道理：「嗯，確實是個進步。」
這時新來的研究生髮言了：「經理，用Maven吧，這個在開源社區很流行，比Ant更方便。」小張一聽很驚訝，Maven真比本身的「規範化Ant」強大？其實他不知道本身只是在從新發明輪子，Maven已經有一大把現成的插件，全世界都在用，你本身不用寫任何代碼！
 爲何沒有人說「我本身寫的代碼最靈活，因此我不用Spring，我本身實現IoC；我不用Hibernate，我本身封裝JDBC」？ ###1.3. Maven與極限編程(XP)###  極限編程是敏捷開發的一種，極限編程是一個輕量級的、靈巧的軟件開發方法；同時它也是一個很是嚴謹和周密的方法。它的基礎和價值觀是交流、樸素、反饋和勇氣；即，任何一個軟件項目均可以從四個方面入手進行改善：增強交流；從簡單作起；尋求反饋；敢於實事求是。XP是一種近螺旋式的開發方法，它將複雜的開發過程分解爲一個個相對比較簡單的小週期；經過積極的交流、反饋以及其它一系列的方法，開發人員和客戶能夠很是清楚開發進度、變化、待解決的問題和潛在的困難等，並根據實際狀況及時地調整開發過程。
 極限編程（XP）是近些年在軟件行業紅得發紫的敏捷開發方法，它強調擁抱變化。該軟件開發方法的創始人Kent Beck提出了XP所追求的價值、實施原則和推薦實踐。下面看一下Maven是如何適應XP的。
 首先看一下Maven如何幫助XP團隊實現一些核心價值：

• 簡單。
   Maven暴露了一組一致、簡潔的操做接口，能幫助團隊成員從原來的高度自定義的、複雜的構建系統中解脫出來，使用Maven現有的成熟的、穩定的組件也能簡化構建系統的複雜度。
• 交流與反饋。  與版本控制系統結合後，全部人都能執行最新的構建並快速獲得反饋。此外，自動生成的項目報告也能幫助成員瞭解項目的狀態，促進團隊的交流。

 此外，Maven更能無縫地支持或者融入到一些主要的XP實踐中：

• 測試驅動開發（TDD）。
   TDD強調測試先行，全部產品都應該由測試用例覆蓋。而測試是Maven生命週期的最重要的組成部分之一，而且Maven有現成的成熟插件支持業界流行的測試框架，如JUnit和TestNG。
• 十分鐘構建。
   十分鐘構建強調咱們可以隨時快速地從源碼構建出最終的產品。這正是Maven所擅長的，只須要一些配置，以後用一條簡單的命令就能讓Maven幫你清理、編譯、測試、打包、部署，而後獲得最終的產品。
• 持續集成（CI）。
   CI強調項目以很短的週期（如15分鐘）集成最新的代碼。實際上,CI的前提是源碼管理系統和構建系統。目前業界流行的CI服務器如Hudson和CruiseControl都能很好地和Maven進行集成。也就是說，使用Maven後，持續集成會變得更加方便。
• 富有信息的工做區。  這條實踐強調開發者可以快速方便地瞭解到項目的最新狀態。固然，Maven並不會幫你把測試覆蓋率報告貼到牆上，也不會在你的工做臺上放個鴨子告訴你構建失敗了。不過使用Maven發佈的項目報告站點，並配置你須要的項目報告，如測試覆蓋率報告，都能幫你把信息推送到開發者眼前。  上述這些實踐並不是只在XP中適用。事實上，除了其餘敏捷開發方法如SCRUM以外，幾乎任何軟件開發方法都能借鑑這些實踐。也就是說，Maven幾乎可以很好地支持任何軟件開發方法。  例如，在傳統的瀑布模型開發中，項目依次要經歷需求開發、分析、設計、編碼、測試和集成發佈階段。從設計和編碼階段開始，就可使用Maven來創建項目的構建系統。在設計階段，也徹底能夠針對設計開發測試用例，而後再編寫代碼來知足這些測試用例。然而，有了自動化構建系統，咱們能夠節省不少手動的測試時間。此外，儘早地使用構建系統集成團隊的代碼，對項目也是百利而無一害。最後，Maven還能幫助咱們快速地發佈項目。