比如你在構建一個項目的發(fā)布版本時，你要把一個文件拷貝到指定的位置，你在項目的元數據那里添加了版本的描述，如果版本號匹配一個特定的數字時，就把文件從A拷貝到B處。如果你依賴XML來構建，你要實現這個任務就像噩夢一樣，你只能通過非標準的機制來添加一些腳本到構建中，結果就是把XML和腳本混在一起，隨著時間的推移，你會添加越來越多的自定義的代碼，結果就是項目越來越復雜很難維護。為什么不考慮用表達式的語言來定義你的構建邏輯呢？

另外一個例子，Maven跟隨約定優(yōu)于配置的規(guī)范，引入了標準化的項目布局和構建生命周期，給很多項目確保一個統(tǒng)一的結構這是個不錯的方法。然而你手上的項目剛好和傳統(tǒng)的約定不一樣。Maven的一個嚴格的約定就是每個項目都要生成一個artifact，比如jar文件，但是你怎么從同一個源代碼結構中創(chuàng)建兩個不同的JAR文件,因此你不得不分開創(chuàng)建兩個項目。

Java構建工具的發(fā)展

最早出現的是Ant，Ant里的每一個任務（target）都可以互相依賴，Ant的最大缺點就是依賴的外部庫也要添加到版本控制系統(tǒng)中，因為Ant沒有一個機制來把這些jar文件放在一個中央庫里面，結果就是不斷的拷貝和粘貼代碼。

隨后Maven在2004年出現了，Maven引入了標準的項目和路徑結構，還有依賴管理，不幸的是自定義的邏輯很難實現，唯一的方法就是引入插件。

隨后Ant通過Apache Ivy引入依賴管理來跟上Maven的腳步，Ant和Ivy集成實現了聲明式的依賴，比如項目的編譯和打包過程

Gradle的出現滿足了很多現在構建工具的需求，Gradle提供了一個DSL(領域特定語言)，一個約定優(yōu)于配置的方法，還有更強大的依賴管理，Gradle使得我們可以拋棄XML的繁瑣配置，引入動態(tài)語言Groovy來定義你的構建邏輯。

為什么要選擇Gradle

假如你是一個開發(fā)者，項目自動構建是你每天工作的一部分，難道你就不想讓你的構建代碼和你寫的源代碼一樣可以擴展、測試和維護？Gradle的構建腳本是聲明式的、可讀的，可以清晰的表達意圖。使用Groovy代替XML來寫代碼大大減少了構建代碼的大小。更重要的是，Gradle集成了其他構建工具，比如Ant和Maven，使得原來的項目很容易遷徙到Gradle。