一、Gradle介紹

Gradle和Maven作為自動構建工具，在專案的構建中有著廣泛的應用。他們之間有各自的優缺點，這裡我們討論下他們在專案構建中的一些區別並進行比較。

首先簡單介紹下Gradle和Maven。Maven主要服務於基於java平臺的專案構建、依賴管理和專案資訊管理。無論是小型的開源類庫專案，還是大型的企業級應用；無論是傳統的瀑布式開發還是流行的敏捷模式，Maven都能大顯身手。Gradle是以groovy語言為基礎，面向java應用為主，基於DSL語法的自動化構建工具。

雖然兩種構建工具有著很多相似處，但是在依賴管理、構建生命週期、載入構建系統元件等許多方面兩者有著許多區別。Maven使用XML來定義生成指令碼，而 Gradle構建指令碼是用Groovy。 用XML的優勢在於它可以更方便地定義構建邏輯，但這是比較複雜的步驟。 用Groovy的好處是寫起來比XML標籤要簡潔許多。 不過熟悉的XML的開發人員比groovy的多，並且複雜的邏輯必須由自己編寫。類似於Maven的pom.xml檔案，每個Gradle專案都需要有一個對應的build.gradle檔案，該檔案定義一些任務（task）來完成構建工作，當然，每個任務是可配置的，任務之間也可以依賴，使用者亦能配置預設任務。

二、依賴管理

通常的Maven專案有一個單一的依賴的靜態配置， 所以一個專案應該只有一個單一的Artifact。 因此其具備了簡單的特點但同時也由於單一缺乏彈性。 Gradle在這方面的更靈活， 可以在建立和處理的時候有多套依賴配置。這裡我們舉一個例子，原本的Maven POM配置是：

<properties>
 <kaptcha.version>2.3</kaptcha.version>
</properties>

<dependencies>
 <dependency>
  <groupId>com.google.code.kaptcha</groupId>
  <artifactId>kaptcha</artifactId>
  <version>${kaptcha.version}</version>
  <classifier>jdk15</classifier>
 </dependency>
 <dependency>
  <groupId>org.springframework</groupId>
  <artifactId>spring-core</artifactId>
 </dependency>
 <dependency>
  <groupId>org.springframework</groupId>
  <artifactId>spring-beans</artifactId>
 </dependency>
 <dependency>
  <groupId>org.springframework</groupId>
  <artifactId>spring-context</artifactId>
 </dependency>
 <dependency>
  <groupId>junit</groupId>
  <artifactId>junit</artifactId>
 </dependency>
</dependencies>

然後我將其轉換成Gradle指令碼，結果是驚人的：

dependencies {
 compile('org.springframework:spring-core:2.5.6')
 compile('org.springframework:spring-beans:2.5.6')
 compile('org.springframework:spring-context:2.5.6')
 compile('com.google.code.kaptcha:kaptcha:2.3:jdk15')
 testCompile('junit:junit:4.7')
}

我們可以發現配置程式碼減少為原來的四分之一。這還不算我省略的一些父POM配置。最重要的是依賴的groupId、artifactId、 version，scope甚至是classfier，一點都不少。並且Gradle能夠解析現有的Maven POM或者Ivy的XML配置，從而得到傳遞性以來的資訊，並且引入到當前專案中，它也支援排除傳遞性依賴或者乾脆關閉傳遞性依賴，Gradle當你排除一項任務時，所有依賴於此任務的任務都會自動被排除如果他們之間沒有其他依賴關係，這是Maven所不具備的特性。

三、載入構建系統的元件

Maven中每個用於構建的元件（編譯/jar等）都作為一個外掛， 每個外掛都有它自己的版本和依賴關係樹。 Gradle的構建系統元件都是分散的。 Maven外掛的優點是在於可以獨立更新，無需整個系統更新。Gradle的模型的優點是編譯需要核心元件以外的元件時才下載。與此同時Gradle給了使用者足夠的自由去定義自己的任務，Gradle每個任務都有一個描述,可以分配到一個組。Maven中外掛和命令可以描述。比如Gradle你可以排除任何執行的任務。在Maven中沒有通用的排除機制，必須用外掛來實現它。而且Gradle具有高階任務排序的特性，任務之間的依賴關係被建立之後能夠得到完全控制，因為Gradle具有強大的語言結構來描述任務之間的執行順序，即使任務並不取決於對方的輸出。Gradle支援動態任務建立，有時你想要一個任務的行為取決於或無限價值的大範圍的引數。一個很好的表達方式提供這樣的任務是任務規則。並且執行任務時，Gradle 在遇到第一次失敗時不停止，執行每一個要執行的任務其中所有的任務依賴關係都要被完成且沒有失敗。任務可以被分配去完成其他任務類似於java中的終結原則。他們總是在另一個任務執行之後執行，不管這個任務是否失敗了。可以發現在一個單一的執行中許多失敗任務會被很好地記錄成一個錯誤報告並最終被彙總。

四、構建生命週期

Maven提供有限的構建生命週期訪問，外掛可以連線到生命週期的特定階段，而且只有在核心外掛執行。而Gradle可以訪問生成的一部分並允許用Groovy程式碼進行處理。Gradle Java Plugin也定義了構建生命週期，包括編譯主程式碼、處理資源、編譯測試程式碼、執行測試、上傳歸檔等等任務，Gradle的構建生命週期如下圖：

相對於Maven完全線性的生命週期，Gradle的構建生命週期略微複雜，不過也更為靈活，例如jar這個任務是用來打包的，它不像Maven那樣依賴於執行測試的test任務，類似的，從圖中可以看到，一個最終的build任務也沒有依賴於uploadArchives任務。這個生命週期並沒有將使用者限制得很死，由於Gradle完全是基於靈活的任務模型，因此很多事情包括覆蓋現有任務，跳過任務都非常易於實現。而這些事情，在Maven的世界中，實現起來就比較的麻煩，或者說Maven就不希望使用者這麼做。

除了以上幾個Maven核心內容與Gradle的區別，在面向物件輸出模式，GUI操作介面、宣告元素等方面Gradle也有良好表現。構建輸出是構建使用者體驗的重要部分。在其他大多數構建工具中預設輸出對於一個構建作者試圖除錯一個問題來說是有關聯的。這通常會導致一個非常詳細的輸出會隱藏重要的警告和訊息實際上是相關的開發人員執行構建。Gradle的預設輸出是針對開發人員執行構建和只顯示訊息相關的情況下而不是濫用日誌輸出作為一種進度，例如在執行測試的時候。構建輸出為構建使用者體驗是非常重要的。如果你與外部工具和庫整合他們的控制檯輸出可能非常冗長。Gradle系統中你可以定義每個外部工具結合的日誌級別的輸出應該被路由。Gradle提供GUI操作介面，這是一個獨立的使用者介面，可以啟動GUI選項，通過自定義日誌模式你可以替換它的日誌與自己的UI。Gradle有許多細粒度的宣告性元素,如SourceSets或Android Product Flavors。它們的核心Gradle DSL然後讓Gradle構建語言更加豐富。他們不斷構建簡潔、易於使用、維護和理解即使你有複雜的需求。Maven沒有細粒宣告元素，這是Maven極端頑固的主要原因。在Gradle,每個外掛都可以提供自己的粗或細粒宣告元素。這使你可以提供一個宣告性方法甚至定製域。它還允許其他技術整合在Gradle中,讓它被更多人使用。

整體來講，Gradle給人一種簡潔靈活的體驗，然而必須掌握groovy也是他的問題，而且由於其靈活性，導致人們更容易破壞約定以至於讓構建變得難以理解。但是Gradle確實是Maven理念的優秀實現。如果足夠了解Groovy，也理解Maven的配置和構建，Gradle會是絕佳選擇，尤其是它幾乎能和現有的Maven系統無縫整合，而且你也能享受到簡潔帶來的極大樂趣，相信Gradle作為後起之秀在今後能夠被完善的更好。

以上就是Gradle相對於Maven有哪些優點的詳細內容，更多關於Gradle和Maven的資料請關注我們其它相關文章！