Maven不是Java領域唯一的構建管理的解決方案。本節將通過一些簡單的例子解釋Maven的必要性，並介紹其他構建解決方案，如IDE、Make和Ant，並將它們與Maven進行比較。

1.2.1  組裝PC和品牌PC

筆者初中時開始接觸計算機，到了高中時更是夢寐以求希望擁有一臺自己的計算機。我的第一臺計算機是賽揚733的，選購是一個漫長的過程，我先閱讀了大量的雜誌以瞭解各類配件的優劣，CPU、記憶體、主機板、顯示卡，甚至音效卡，我都仔細地挑選，後來還跑了很多商家，調貨、討價還價，組裝好後自己裝作業系統和驅動程式……雖然這花費了我大量時間，但我很享受這個過程。可是事實證明，裝出來的機器穩定性不怎麼好。

一年前我需要配一臺工作站，這時候我已經沒有太多時間去研究電腦配件了。我選擇了某知名PC供應商的線上商店，大概瀏覽了一下主流的機型，選擇了我需要的配置，然後下單、付款。接著PC供應商幫我組裝電腦、安裝作業系統和驅動程式。一週後，物流公司將電腦送到我的家裡，我接上顯示器、電源、滑鼠和鍵盤就能直接使用了。這為我節省了大量時間，而且這臺電腦十分穩定，商家在把電腦傳送給我之前已經進行了很好的測試。對了，我還能享受兩年的售後服務。

使用指令碼建立高度自定義的構建系統就像買組裝PC，耗時費力，結果也不一定很好。當然，你可以享受從無到有的樂趣，但恐怕實際專案中無法給你那麼多時間。使用Maven就像購買品牌PC

1.2.2  IDE不是萬能的

當然，我們無法否認優秀的IDE能大大提高開發效率。當前主流的IDE如Eclipse和NetBeans等都提供了強大的文字編輯、除錯甚至重構功能。雖然使用簡單的文字編輯器和命令列也能完成絕大部分開發工作，但很少有人願意那樣做。然而，IDE是有其天生缺陷的：

• IDE依賴大量的手工操作。編譯、測試、程式碼生成等工作都是相互獨立的，很難一鍵完成所有工作。手工勞動往往意味著低效，意味著容易出錯。
• 很難在專案中統一所有的IDE配置，每個人都有自己的喜好。也正是由於這個原因，一個在機器A上可以成功執行的任務，到了機器B的IDE中可能就會失敗。

我們應該合理利用IDE，而不是過多地依賴它。對於構建這樣的任務，在IDE中一次次地點選滑鼠是愚蠢的行為。Maven是這方面的專家，而且主流IDE都集成了Maven，我們可以在IDE中方便地執行Maven執行構建。

1.2.3  Make

Make也許是最早的構建工具，它由StuartFeldman於1977年在Bell實驗室建立。Stuart Feldman也因此於2003年獲得了ACM國際計算機組織頒發的軟體系統獎。目前Make有很多衍生實現，包括最流行的GNU Make和BSD Make，還有Windows平臺的Microsoft nmake等。

Make由一個名為Makefile的指令碼檔案驅動，該檔案使用Make自己定義的語法格式。其基本組成部分為一系列規則（Rules），而每一條規則又包括目標（Target）、依賴（Prerequisite）和命令（Command）。Makefile的基本結構如下：

1. <span style=< span="">"font-size: small;">TARGET… : PREREQUISITE…  </span style=<>
2. COMMAND  
3. …  
4. …  

    Make通過一系列目標和依賴將整個構建過程串聯起來，同時利用本地命令完成每個目標的實際行為。Make的強大之處在於它可以利用所有系統的本地命令，尤其是UNIX/Linux系統，豐富的功能、強大的命令能夠幫助Make快速高效地完成任務。

但是，Make將自己和作業系統繫結在一起了。也就是說，使用Make，就不能實現（至少很難）跨平臺的構建，這對於Java來說是非常不友好的。此外，Makefile的語法也成問題，很多人抱怨Make構建失敗的原因往往是一個難以發現的空格或Tab使用錯誤。

1.2.4  Ant

Ant不是指螞蟻，而是意指“另一個整潔的工具”（Another Neat Tool），它最早用來構建著名的Tomcat，其作者James Duncan Davidson創作它的動機就是因為受不了Makefile的語法格式。我們可以將Ant看成是一個Java版本的Make，也正因為使用了Java，Ant是跨平臺的。此外，Ant使用XML定義構建指令碼，相對於Makefile來說，這也更加友好。

與Make類似，Ant有一個構建指令碼build.xml，如下所示：

build.xml的基本結構也是目標（target）、依賴（depends），以及實現目標的任務。比如在上面的指令碼中，jar目標用來建立應用程式jar檔案，該目標依賴於compile目標，後者執行的任務是建立一個名為classes的資料夾，編譯當前目錄的java檔案至classes目錄。compile目標完成後，jar目標再執行自己的任務。Ant有大量內建的用Java實現的任務，這保證了其跨平臺的特質，同時，Ant也有特殊的任務exec來執行本地命令。

和Make一樣，Ant也都是過程式的，開發者顯式地指定每一個目標，以及完成該目標所需要執行的任務。針對每一個專案，開發者都需要重新編寫這一過程，這裡其實隱含著很大的重複。Maven是宣告式的，專案構建過程和過程各個階段所需的工作都由外掛實現，並且大部分外掛都是現成的，開發者只需要宣告專案的基本元素，Maven就執行內建的、完整的構建過程。這在很大程度上消除了重複。

Ant是沒有依賴管理的，所以很長一段時間Ant使用者都不得不手工管理依賴，這是一個令人頭疼的問題。幸運的是，Ant使用者現在可以藉助Ivy管理依賴。而對於Maven使用者來說，依賴管理是理所當然的，Maven不僅內建了依賴管理，更有一個可能擁有全世界最多Java開源軟體包的中央倉庫，Maven使用者無須進行任何配置就可以直接享用。

1.2.5  不重複發明輪子

【該小節內容整理自網友Arthas最早在Maven中文MSN的群內的討論，在此表示感謝】

小張是一家小型民營軟體公司的程式設計師，他所在的公司要開發一個新的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”？