gradle和maven有哪些區別

gradle和maven都可以用來構建java程序，甚至在某些情況下，兩者還可以互相轉換，那麼他們兩個的共同點和不同點是什麼？我們如何在項目中選擇使用哪種技術呢？一起來看看吧。

gradle和maven的比較

雖然gradle和maven都可以作為java程序的構建工具。但是兩者還是有很大的不同之處的。我們可以從下面幾個方面來進行分析。

可擴展性

Google選擇gradle作為android的構建工具不是沒有理由的，其中一個非常重要的原因就是因為gradle夠靈活。一方面是因為gradle使用的是groovy或者kotlin語言作為腳本的編寫語言，這樣極大的提高瞭腳本的靈活性，但是其本質上的原因是gradle的基礎架構能夠支持這種靈活性。

你可以使用gradle來構建native的C/C++程序，甚至擴展到任何語言的構建。

相對而言，maven的靈活性就差一些，並且自定義起來也比較麻煩，但是maven的項目比較容易看懂，並且上手簡單。

所以如果你的項目沒有太多自定義構建需求的話還是推薦使用maven，但是如果有自定義的構建需求，那麼還是投入gradle的懷抱吧。

性能比較

雖然現在大傢的機子性能都比較強勁，好像在做項目構建的時候性能的優勢並不是那麼的迫切，但是對於大型項目來說，一次構建可能會需要很長的時間，尤其對於自動化構建和CI的環境來說，當然希望這個構建是越快越好。

Gradle和Maven都支持並行的項目構建和依賴解析。但是gradle的三個特點讓gradle可以跑的比maven快上一點：

增量構建

gradle為瞭提升構建的效率，提出瞭增量構建的概念，為瞭實現增量構建，gradle將每一個task都分成瞭三部分，分別是input輸入，任務本身和output輸出。下圖是一個典型的java編譯的task。

以上圖為例，input就是目標jdk的版本，源代碼等，output就是編譯出來的class文件。

增量構建的原理就是監控input的變化，隻有input發送變化瞭，才重新執行task任務，否則gradle認為可以重用之前的執行結果。

所以在編寫gradle的task的時候，需要指定task的輸入和輸出。

並且要註意隻有會對輸出結果產生變化的才能被稱為輸入，如果你定義瞭對初始結果完全無關的變量作為輸入，則這些變量的變化會導致gradle重新執行task，導致瞭不必要的性能的損耗。

還要註意不確定執行結果的任務，比如說同樣的輸入可能會得到不同的輸出結果，那麼這樣的任務將不能夠被配置為增量構建任務。

構建緩存

gradle可以重用同樣input的輸出作為緩存，大傢可能會有疑問瞭，這個緩存和增量編譯不是一個意思嗎？

在同一個機子上是的，但是緩存可以跨機器共享.如果你是在一個CI服務的話，build cache將會非常有用。因為developer的build可以直接從CI服務器上面拉取構建結果，非常的方便。

Gradle守護進程

gradle會開啟一個守護進程來和各個build任務進行交互，優點就是不需要每次構建都初始化需要的組件和服務。

同時因為守護進程是一個一直運行的進程，除瞭可以避免每次JVM啟動的開銷之外，還可以緩存項目結構，文件，task和其他的信息，從而提升運行速度。

我們可以運行 gradle –status 來查看正在運行的daemons進程。

從Gradle 3.0之後，daemons是默認開啟的，你可以使用 org.gradle.daemon=false 來禁止daemons。

我們可以通過下面的幾個圖來直觀的感受一下gradle和maven的性能比較：

使用gradle和maven構建 Apache Commons Lang 3的比較：

使用gradle和maven構建小項目（10個模塊，每個模塊50個源文件和50個測試文件）的比較：

使用gradle和maven構建大項目（500個模塊，每個模塊100個源文件和100個測試文件）的比較：

可以看到gradle性能的提升是非常明顯的。

依賴的區別

gralde和maven都可以本地緩存依賴文件，並且都支持依賴文件的並行下載。

在maven中隻可以通過版本號來覆蓋一個依賴項。而gradle更加靈活，你可以自定義依賴關系和替換規則，通過這些替換規則，gradle可以構建非常復雜的項目。

從maven遷移到gradle

因為maven出現的時間比較早，所以基本上所有的java項目都支持maven，但是並不是所有的項目都支持gradle。如果你有需要把maven項目遷移到gradle的想法，那麼就一起來看看吧。

根據我們之前的介紹，大傢可以發現gradle和maven從本質上來說就是不同的，gradle通過task的DAG圖來組織任務，而maven則是通過attach到phases的goals來執行任務。

雖然兩者的構建有很大的不同，但是得益於gradle和maven相識的各種約定規則，從maven移植到gradle並不是那麼難。

要想從maven移植到gradle，首先要瞭解下maven的build生命周期，maven的生命周期包含瞭clean，compile，test，package，verify，install和deploy這幾個phase。

我們需要將maven的生命周期phase轉換為gradle的生命周期task。這裡需要使用到gradle的Base Plugin，Java Plugin和Maven Publish Plugin。

先看下怎麼引入這三個plugin：

plugins {
  id 'base'
  id 'java'
  id 'maven-publish'
}

clean會被轉換成為clean task，compile會被轉換成為classes task，test會被轉換成為test task，package會被轉換成為assemble task，verify 會被轉換成為check task，install會被轉換成為 Maven Publish Plugin 中的publishToMavenLocal task，deploy 會被轉換成為Maven Publish Plugin 中的publish task。

有瞭這些task之間的對應關系，我們就可以嘗試進行maven到gradle的轉換瞭。

自動轉換

我們除瞭可以使用 gradle init 命令來創建一個gradle的架子之外，還可以使用這個命令來將maven項目轉換成為gradle項目，gradle init命令會去讀取pom文件，並將其轉換成為gradle項目。

轉換依賴

gradle和maven的依賴都包含瞭group ID, artifact ID 和版本號。兩者本質上是一樣的，隻是形式不同，我們看一個轉換的例子：

<dependencies>
  <dependency>
    <groupId>log4j</groupId>
    <artifactId>log4j</artifactId>
    <version>1.2.12</version>
  </dependency>
</dependencies>

上是一個maven的例子，我們看下gradle的例子怎寫：

dependencies {
  implementation 'log4j:log4j:1.2.12' 
}

可以看到gradle比maven寫起來要簡單很多。

註意這裡的implementation實際上是由 Java Plugin 來實現的。

我們在maven的依賴中有時候還會用到scope選項，用來表示依賴的范圍，我們看下這些范圍該如何進行轉換：

compile：

在gradle可以有兩種配置來替換compile，我們可以使用implementation或者api。

前者在任何使用Java Plugin的gradle中都可以使用，而api隻能在使用Java Library Plugin的項目中使用。

當然兩者是有區別的，如果你是構建應用程序或者webapp，那麼推薦使用implementation，如果你是在構建Java libraries，那麼推薦使用api。

runtime：

可以替換成 runtimeOnly 。

test：

gradle中的test分為兩種，一種是編譯test項目的時候需要，那麼可以使用testImplementation，一種是運行test項目的時候需要，那麼可以使用testRuntimeOnly。

provided：

可以替換成為compileOnly。

import：

在maven中，import經常用在dependencyManagement中，通常用來從一個pom文件中導入依賴項，從而保證項目中依賴項目版本的一致性。

在gradle中，可以使用 platform() 或者 enforcedPlatform() 來導入pom文件：

dependencies {
  implementation platform('org.springframework.boot:spring-boot-dependencies:1.5.8.RELEASE') 

  implementation 'com.google.code.gson:gson' 
  implementation 'dom4j:dom4j'
}

比如上面的例子中，我們導入瞭spring-boot-dependencies。因為這個pom中已經定義瞭依賴項的版本號，所以我們在後面引入gson的時候就不需要指定版本號瞭。

platform和enforcedPlatform的區別在於，enforcedPlatform會將導入的pom版本號覆蓋其他導入的版本號：

dependencies {
  // import a BOM. The versions used in this file will override any other version found in the graph
  implementation enforcedPlatform('org.springframework.boot:spring-boot-dependencies:1.5.8.RELEASE')

  // define dependencies without versions
  implementation 'com.google.code.gson:gson'
  implementation 'dom4j:dom4j'

  // this version will be overridden by the one found in the BOM
  implementation 'org.codehaus.groovy:groovy:1.8.6'
}

轉換repositories倉庫

gradle可以兼容使用maven或者lvy的repository。gradle沒有默認的倉庫地址，所以你必須手動指定一個。

你可以在gradle使用maven的倉庫：

repositories {
  mavenCentral()
}

我們還可以直接指定maven倉庫的地址：

repositories {
  maven {
    url "http://repo.mycompany.com/maven2"
  }
}

如果你想使用maven本地的倉庫，則可以這樣使用：

repositories {
  mavenLocal()
}

但是mavenLocal是不推薦使用的，為什麼呢？

mavenLocal隻是maven在本地的一個cache，它包含的內容並不完整。比如說一個本地的maven repository module可能隻包含瞭jar包文件，並沒有包含source或者javadoc文件。那麼我們將不能夠在gradle中查看這個module的源代碼，因為gradle會首先在maven本地的路徑中查找這個module。

並且本地的repository是不可信任的，因為裡面的內容可以輕易被修改，並沒有任何的驗證機制。

控制依賴的版本

如果同一個項目中對同一個模塊有不同版本的兩個依賴的話，默認情況下Gradle會在解析完DAG之後，選擇版本最高的那個依賴包。

但是這樣做並不一定就是正確的， 所以我們需要自定義依賴版本的功能。

首先就是上面我們提到的使用platform()和enforcedPlatform() 來導入BOM（packaging類型是POM的）文件。

如果我們項目中依賴瞭某個module，而這個module又依賴瞭另外的module，我們叫做傳遞依賴。在這種情況下，如果我們希望控制傳遞依賴的版本，比如說將傳遞依賴的版本升級為一個新的版本，那麼可以使用dependency constraints：

dependencies {
  implementation 'org.apache.httpcomponents:httpclient'
  constraints {
    implementation('org.apache.httpcomponents:httpclient:4.5.3') {
      because 'previous versions have a bug impacting this application'
    }
    implementation('commons-codec:commons-codec:1.11') {
      because 'version 1.9 pulled from httpclient has bugs affecting this application'
    }
  }
}

註意，dependency constraints隻對傳遞依賴有效，如果上面的例子中commons-codec並不是傳遞依賴，那麼將不會有任何影響。

同時 Dependency constraints需要Gradle Module Metadata的支持，也就是說隻有你的module是發佈在gradle中才支持這個特性，如果是發佈在maven或者ivy中是不支持的。

上面講的是傳遞依賴的版本升級。同樣是傳遞依賴，如果本項目也需要使用到這個傳遞依賴的module，但是需要使用到更低的版本（因為默認gradle會使用最新的版本），就需要用到版本降級瞭。

dependencies {
  implementation 'org.apache.httpcomponents:httpclient:4.5.4'
  implementation('commons-codec:commons-codec') {
    version {
      strictly '1.9'
    }
  }
}

我們可以在implementation中指定特定的version即可。

strictly表示的是強制匹配特定的版本號，除瞭strictly之外，還有require，表示需要的版本號大於等於給定的版本號。prefer，如果沒有指定其他的版本號，那麼就使用prefer這個。reject，拒絕使用這個版本。

除此之外，你還可以使用Java Platform Plugin來指定特定的platform，從而限制版本號。

最後看一下如何exclude一個依賴：

dependencies {
  implementation('commons-beanutils:commons-beanutils:1.9.4') {
    exclude group: 'commons-collections', module: 'commons-collections'
  }
}

多模塊項目

maven中可以創建多模塊項目：

<modules>
  <module>simple-weather</module>
  <module>simple-webapp</module>
</modules>

我們可以在gradle中做同樣的事情settings.gradle：

rootProject.name = 'simple-multi-module' 

include 'simple-weather', 'simple-webapp'

profile和屬性

maven中可以使用profile來區別不同的環境，在gradle中，我們可以定義好不同的profile文件，然後通過腳本來加載他們：

build.gradle：

if (!hasProperty('buildProfile')) ext.buildProfile = 'default' 

apply from: "profile-${buildProfile}.gradle" 

task greeting {
  doLast {
    println message 
  }
}

profile-default.gradle：

ext.message = 'foobar'

profile-test.gradle：

ext.message = 'testing 1 2 3'

我們可以這樣來運行：

> gradle greeting
foobar

> gradle -PbuildProfile=test greeting
testing 1 2 3

資源處理

在maven中有一個process-resources階段，可以執行resources:resources用來進行resource文件的拷貝操作。

在Gradle中的Java plugin的processResources task也可以做相同的事情。

比如我可以執行copy任務：

task copyReport(type: Copy) {
  from file("buildDir/reports/my-report.pdf")
  into file("buildDir/toArchive")
}

更加復雜的拷貝：

task copyPdfReportsForArchiving(type: Copy) {
  from "buildDir/reports"
  include "*.pdf"
  into "buildDir/toArchive"
}

當然拷貝還有更加復雜的應用。這裡就不詳細講解瞭。

以上就是gradle和maven有哪些區別的詳細內容，更多關於gradle和maven 區別的資料請關註WalkonNet其它相關文章！

推薦閱讀：

• Java用 Gradle配置compile及implementation和api的區別
• Java中的Gradle與Groovy的區別及存在的關系
• Maven使用方法詳及方式詳細介紹
• 現代高效的java構建工具gradle的快速入門
• Android Gradle 三方依賴管理詳解