Gradle相對于Maven的優點有哪些

這期內容當中小編將會給大家帶來有關Gradle相對于Maven的優點有哪些，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

一、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的優點有哪些了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。