Ant、Maven或是其他？談Java構建工具的未來

不久之前部落格Adam Bien寫了關於一篇關於老話題：Ant或者Maven的文章，文中有寫道“Maven的真正厲害之處是它的依賴管理（dependency management），要做許多工作才能讓Ant的依賴管理達到Maven的程度……”文章對Maven似乎有所偏愛，這引起來了Adam Pohorecki的爭論，並由此進一步談到了Java構建工具的未來：

儘管Ant沒有內建的依賴管理是個事實，但是將Ivy整合到你build.xml中還是很簡單的，所以我認為Adam Bien所說的“許多工作”是個誤導。

如果要我在Ant和Maven之間選擇，我會選擇前者。我也理解為什麼很多人喜歡將Maven作為他們首選的構建工具，因為它有構建指令碼，只需要幾行代碼來配置就可以有許多功能：依賴管理、內建的編譯和打包應用的任務、與Jetty的整合、乾淨的項目web網址，與cobertura的整合、pmd或者 findbugs。在這種情況下，如果你啟動的項目非常常規（使用Spring & Hibernate的應用），Maven就是非常好的選擇。

沒有人想寫構建指令碼，因為這種代碼沒有任何真正的商業價值。如果沒有遇到問題，你會覺得Maven真的很棒。但也許你的項目不是常規的，也許你使用的外掛程式彼此衝突，在Maven這樣的構建系統中有許多失敗的地方，而且經常你很難找到它們的來源並修複它們。

Ant比Maven更值得選擇的優點並不明顯。而且Ant用手來編寫所有的構建代碼確實很遭罪。但一旦搞定之後，構建指令碼就真正成了你的代碼。而且在運行出現問題時，你可以檢查代碼並修改之，不必像無頭蒼蠅一樣無跡可尋。

但是，Maven和Ant就只是我們的選擇嗎？是否還有比它們更好的選擇？在過去的幾年中，我們看到很多項目，他們使用的工具不再使用XML來定義構建邏輯，而是真正的程式設計語言像Groovy、Ruby、Python，它們經常允許依賴管理。這裡有幾個：GRADLE 、Gant、Kundo、 Raven、 Buildr。

我最愛的構建工具是Gant，它至今也不過發布了幾個月而已。Gant基本是一種Groovy的方式調用了Ant任務，比較起老舊的build.xml它有很多優點。通過使用真正的程式設計語言而不是XML，許多本來在XML中很是枯燥的任務變得簡單：將通用代碼提取為方法、迴圈、條件邏輯。實際上，XML並非程式設計語言也不應當被當成程式設計語言來使用。使用像Groovy或者Ruby這樣的語言來構建指令碼更加簡潔、易懂，而且雜亂冗餘的代碼更少，結構上也更清晰。

在我看來，在Java環境構建自動化的未來是Gradle，或者是另外一些有相似特性的工具。Gradle是一種我所喜歡的構建指令碼：如果是簡單、標準的項目你只需要幾行配置就可以搞定。它甚至在不使用Maven或者Ivy套件庫的情況下允許可傳遞的依賴管理（transitive dependency management）。當我們第一次知道“依賴管理”，是用ivy.xml或者pom.xml寫下我們的依賴，然後不得不安裝一個獨立的倉庫（repository ）來儲存這些不能在Maven庫中找到的依賴，不得不修補pom.xml檔案，因為有些沒有聲明它們的依賴。現在這一切可以成為曆史了，我們有DM，只要在SVN庫中儲存我們需要的libs，然後在用到的時候轉到真正的DM就可以了。

而且，如果是大的項目，除了其他特性之外Gradle擁有對多項目構建的第一類（first-class）支援，（比如你可以規定項目依賴，當你構建一個附屬項目時，它的依賴也會被構建好）。Gradle還有其他很多特性，你可以在官網的使用者指南上尋找，大概100多頁。我的意思是如果你肯花點時間來閱讀，你就會發現Gradle將會讓你的開發變得多麼地容易。

但我還是不得不承認，Gradle也許不適合“產品理念”，畢竟項目開發還是個新事物。但如果你想找個更好的工具來替代Ant，Gradle就是。如果你想找工具代替Maven，也許還得等幾個月，因為Gradle目前還沒有支援許多Maven使用者所依賴的特性，比如項目網址、為主要的IDEs產生項目文檔。

概括來說，雖然對自動化構建而言沒有一種方法解決所有問題的解決方案，但正在進步的新工具卻在努力做到這點。既可以按照慣例來構建，也可以按照你自己想要的方法來構建，Gradle在這兩方面既吸引了Ant也吸引了Maven的fans。在我看來，未來構建指令碼是用像Groovy或者Ruby這樣的程式設計語言來編寫的，而Gradle將在工具中佔據重中之重。（譯/王玉磊）