簡要對比Maven和Gradle，送給開發者的你

Java世界中主要有三大構建工具：Ant、Maven和Gradle。通過幾年的發展，Ant幾乎銷聲匿跡，Maven也日薄西山，而Gradle的發展則如日中天。筆者有幸見證了Maven的沒落和Gradle的興起。Maven的主要功能主要分爲5點，分別是依賴管理系統、多模塊構建兩個方面來分析一下Gradle和Maven的區別。

依賴管理系統
Maven爲Java世界引入了一個新的依賴管理系統。在Java世界中，能夠用groupId、artifactId、version組成的Coordination（座標）惟一標識一個依賴。任何基於Maven構建的項目自身也必須定義這三項屬性，生成的包能夠是Jar包，也能夠是war包或者ear包。一個典型的依賴引用以下所示：
<dependency>
 <groupId>junit</groupId>
 <artifactId>junit</artifactId>
 <version>4.12</version>
 <scope>test</scope>
</dependency>
<dependency>
 <groupId>org.springframework</groupId>
 <artifactId>spring-test</artifactId>
</dependency>
從上面能夠看出當引用一個依賴時，version能夠省略掉，這樣在獲取依賴時會選擇最新的版本。而存儲這些組件的倉庫有遠程倉庫和本地倉庫之分。遠程倉庫可使用世界公用的central倉庫，也可使用Apache Nexus自建私有倉庫；本地倉庫則在本地計算機上。經過Maven安裝目錄下的settings.xml文件能夠配置本地倉庫的路徑，以及採用的遠程倉庫的地址。
Gradle在設計的時候基本沿用了Maven的這套依賴管理體系。不過它在引用依賴時仍是進行了一些改進。首先引用依賴方面變得很是簡潔。

dependencies {
 compile 'org.hibernate:hibernate-core:3.6.7.Final'
 testCompile ‘junit:junit:4.+'
}
第二，Maven和Gradle對依賴項的scope有所不一樣。在Maven世界中，一個依賴項有6種scope，分別是complie(默認)、provided、runtime、test、system、import。而grade將其簡化爲了4種，compile、runtime、testCompile、testRuntime。那麼若是想在gradle使用相似於provided的scope怎麼辦？彆着急，因爲gradle語言的強大表現力，咱們能夠輕鬆編寫代碼來實現相似於provided scope的概念（例如How to use provided scope for jar file in Gradle build?）。

第三點是Gradle支持動態的版本依賴。在版本號後面使用+號的方式能夠實現動態的版本管理。
第四點是在解決依賴衝突方面Gradle的實現機制更加明確。使用Maven和Gradle進行依賴管理時都採用的是傳遞性依賴；而若是多個依賴項指向同一個依賴項的不一樣版本時就會引發依賴衝突。而Maven處理這種依賴關係每每是噩夢通常的存在。而Gradle在解決依賴衝突方面相對來講比較明確。

多模塊構建
在SOA和微服務的浪潮下，將一個項目分解爲多個模塊已是很通用的一種方式。在Maven中須要定義個parent POM做爲一組module的聚合POM。在該POM中可使用<modules>標籤來定義一組子模塊。parent POM不會有什麼實際構建產出。而parent POM中的build配置以及依賴配置都會自動繼承給子module。
而Gradle也支持多模塊構建。而在parent的build.gradle中可使用allprojects和subprojects代碼塊來分別定義裏面的配置是應用於全部項目仍是子項目。對於子模塊的定義是放置在setttings.gradle文件中的。在gradle的設計當中，每一個模塊都是Project的對象實例。而在parent build.gradle中經過allprojects或subprojects能夠對這些對象進行各類操做。這無疑比Maven要靈活的多。
好比在parent的build.gradle中有如下代碼：

allprojects {
 task hello << { task -> println "I'm $task.project.name" }
}
執行命令gradle -q hello會依次打印出父module以及各個submodule的項目名稱。這種強大的能力能讓gradle對各個模塊具備更強的定製化。