gradle和maven有哪些區(qū)別
gradle和maven都可以用來構(gòu)建java程序,甚至在某些情況下,兩者還可以互相轉(zhuǎn)換,那么他們兩個的共同點和不同點是什么?我們?nèi)绾卧陧椖恐羞x擇使用哪種技術(shù)呢?一起來看看吧。
gradle和maven的比較
雖然gradle和maven都可以作為java程序的構(gòu)建工具。但是兩者還是有很大的不同之處的。我們可以從下面幾個方面來進行分析。
可擴展性
Google選擇gradle作為android的構(gòu)建工具不是沒有理由的,其中一個非常重要的原因就是因為gradle夠靈活。一方面是因為gradle使用的是groovy或者kotlin語言作為腳本的編寫語言,這樣極大的提高了腳本的靈活性,但是其本質(zhì)上的原因是gradle的基礎(chǔ)架構(gòu)能夠支持這種靈活性。
你可以使用gradle來構(gòu)建native的C/C++程序,甚至擴展到任何語言的構(gòu)建。
相對而言,maven的靈活性就差一些,并且自定義起來也比較麻煩,但是maven的項目比較容易看懂,并且上手簡單。
所以如果你的項目沒有太多自定義構(gòu)建需求的話還是推薦使用maven,但是如果有自定義的構(gòu)建需求,那么還是投入gradle的懷抱吧。
性能比較
雖然現(xiàn)在大家的機子性能都比較強勁,好像在做項目構(gòu)建的時候性能的優(yōu)勢并不是那么的迫切,但是對于大型項目來說,一次構(gòu)建可能會需要很長的時間,尤其對于自動化構(gòu)建和CI的環(huán)境來說,當(dāng)然希望這個構(gòu)建是越快越好。
Gradle和Maven都支持并行的項目構(gòu)建和依賴解析。但是gradle的三個特點讓gradle可以跑的比maven快上一點:
增量構(gòu)建
gradle為了提升構(gòu)建的效率,提出了增量構(gòu)建的概念,為了實現(xiàn)增量構(gòu)建,gradle將每一個task都分成了三部分,分別是input輸入,任務(wù)本身和output輸出。下圖是一個典型的java編譯的task。
以上圖為例,input就是目標(biāo)jdk的版本,源代碼等,output就是編譯出來的class文件。
增量構(gòu)建的原理就是監(jiān)控input的變化,只有input發(fā)送變化了,才重新執(zhí)行task任務(wù),否則gradle認為可以重用之前的執(zhí)行結(jié)果。
所以在編寫gradle的task的時候,需要指定task的輸入和輸出。
并且要注意只有會對輸出結(jié)果產(chǎn)生變化的才能被稱為輸入,如果你定義了對初始結(jié)果完全無關(guān)的變量作為輸入,則這些變量的變化會導(dǎo)致gradle重新執(zhí)行task,導(dǎo)致了不必要的性能的損耗。
還要注意不確定執(zhí)行結(jié)果的任務(wù),比如說同樣的輸入可能會得到不同的輸出結(jié)果,那么這樣的任務(wù)將不能夠被配置為增量構(gòu)建任務(wù)。
構(gòu)建緩存
gradle可以重用同樣input的輸出作為緩存,大家可能會有疑問了,這個緩存和增量編譯不是一個意思嗎?
在同一個機子上是的,但是緩存可以跨機器共享.如果你是在一個CI服務(wù)的話,build cache將會非常有用。因為developer的build可以直接從CI服務(wù)器上面拉取構(gòu)建結(jié)果,非常的方便。
Gradle守護進程
gradle會開啟一個守護進程來和各個build任務(wù)進行交互,優(yōu)點就是不需要每次構(gòu)建都初始化需要的組件和服務(wù)。
同時因為守護進程是一個一直運行的進程,除了可以避免每次JVM啟動的開銷之外,還可以緩存項目結(jié)構(gòu),文件,task和其他的信息,從而提升運行速度。
我們可以運行 gradle –status 來查看正在運行的daemons進程。
從Gradle 3.0之后,daemons是默認開啟的,你可以使用 org.gradle.daemon=false 來禁止daemons。
我們可以通過下面的幾個圖來直觀的感受一下gradle和maven的性能比較:
使用gradle和maven構(gòu)建 Apache Commons Lang 3的比較:
使用gradle和maven構(gòu)建小項目(10個模塊,每個模塊50個源文件和50個測試文件)的比較:
使用gradle和maven構(gòu)建大項目(500個模塊,每個模塊100個源文件和100個測試文件)的比較:
可以看到gradle性能的提升是非常明顯的。
依賴的區(qū)別
gralde和maven都可以本地緩存依賴文件,并且都支持依賴文件的并行下載。
在maven中只可以通過版本號來覆蓋一個依賴項。而gradle更加靈活,你可以自定義依賴關(guān)系和替換規(guī)則,通過這些替換規(guī)則,gradle可以構(gòu)建非常復(fù)雜的項目。
從maven遷移到gradle
因為maven出現(xiàn)的時間比較早,所以基本上所有的java項目都支持maven,但是并不是所有的項目都支持gradle。如果你有需要把maven項目遷移到gradle的想法,那么就一起來看看吧。
根據(jù)我們之前的介紹,大家可以發(fā)現(xiàn)gradle和maven從本質(zhì)上來說就是不同的,gradle通過task的DAG圖來組織任務(wù),而maven則是通過attach到phases的goals來執(zhí)行任務(wù)。
雖然兩者的構(gòu)建有很大的不同,但是得益于gradle和maven相識的各種約定規(guī)則,從maven移植到gradle并不是那么難。
要想從maven移植到gradle,首先要了解下maven的build生命周期,maven的生命周期包含了clean,compile,test,package,verify,install和deploy這幾個phase。
我們需要將maven的生命周期phase轉(zhuǎn)換為gradle的生命周期task。這里需要使用到gradle的Base Plugin,Java Plugin和Maven Publish Plugin。
先看下怎么引入這三個plugin:
plugins { id 'base' id 'java' id 'maven-publish' }
clean會被轉(zhuǎn)換成為clean task,compile會被轉(zhuǎn)換成為classes task,test會被轉(zhuǎn)換成為test task,package會被轉(zhuǎn)換成為assemble task,verify 會被轉(zhuǎn)換成為check task,install會被轉(zhuǎn)換成為 Maven Publish Plugin 中的publishToMavenLocal task,deploy 會被轉(zhuǎn)換成為Maven Publish Plugin 中的publish task。
有了這些task之間的對應(yīng)關(guān)系,我們就可以嘗試進行maven到gradle的轉(zhuǎn)換了。
自動轉(zhuǎn)換
我們除了可以使用 gradle init 命令來創(chuàng)建一個gradle的架子之外,還可以使用這個命令來將maven項目轉(zhuǎn)換成為gradle項目,gradle init命令會去讀取pom文件,并將其轉(zhuǎn)換成為gradle項目。
轉(zhuǎn)換依賴
gradle和maven的依賴都包含了group ID, artifact ID 和版本號。兩者本質(zhì)上是一樣的,只是形式不同,我們看一個轉(zhuǎn)換的例子:
<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 來實現(xiàn)的。
我們在maven的依賴中有時候還會用到scope選項,用來表示依賴的范圍,我們看下這些范圍該如何進行轉(zhuǎn)換:
compile:
在gradle可以有兩種配置來替換compile,我們可以使用implementation或者api。
前者在任何使用Java Plugin的gradle中都可以使用,而api只能在使用Java Library Plugin的項目中使用。
當(dāng)然兩者是有區(qū)別的,如果你是構(gòu)建應(yīng)用程序或者webapp,那么推薦使用implementation,如果你是在構(gòu)建Java libraries,那么推薦使用api。
runtime:
可以替換成 runtimeOnly 。
test:
gradle中的test分為兩種,一種是編譯test項目的時候需要,那么可以使用testImplementation,一種是運行test項目的時候需要,那么可以使用testRuntimeOnly。
provided:
可以替換成為compileOnly。
import:
在maven中,import經(jīng)常用在dependencyManagement中,通常用來從一個pom文件中導(dǎo)入依賴項,從而保證項目中依賴項目版本的一致性。
在gradle中,可以使用 platform() 或者 enforcedPlatform() 來導(dǎo)入pom文件:
dependencies { implementation platform('org.springframework.boot:spring-boot-dependencies:1.5.8.RELEASE') implementation 'com.google.code.gson:gson' implementation 'dom4j:dom4j' }
比如上面的例子中,我們導(dǎo)入了spring-boot-dependencies。因為這個pom中已經(jīng)定義了依賴項的版本號,所以我們在后面引入gson的時候就不需要指定版本號了。
platform和enforcedPlatform的區(qū)別在于,enforcedPlatform會將導(dǎo)入的pom版本號覆蓋其他導(dǎo)入的版本號:
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' }
轉(zhuǎn)換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,它包含的內(nèi)容并不完整。比如說一個本地的maven repository module可能只包含了jar包文件,并沒有包含source或者javadoc文件。那么我們將不能夠在gradle中查看這個module的源代碼,因為gradle會首先在maven本地的路徑中查找這個module。
并且本地的repository是不可信任的,因為里面的內(nèi)容可以輕易被修改,并沒有任何的驗證機制。
控制依賴的版本
如果同一個項目中對同一個模塊有不同版本的兩個依賴的話,默認情況下Gradle會在解析完DAG之后,選擇版本最高的那個依賴包。
但是這樣做并不一定就是正確的, 所以我們需要自定義依賴版本的功能。
首先就是上面我們提到的使用platform()和enforcedPlatform() 來導(dǎo)入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是發(fā)布在gradle中才支持這個特性,如果是發(fā)布在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中可以創(chuàng)建多模塊項目:
<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來區(qū)別不同的環(huán)境,在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階段,可以執(zhí)行resources:resources用來進行resource文件的拷貝操作。
在Gradle中的Java plugin的processResources task也可以做相同的事情。
比如我可以執(zhí)行copy任務(wù):
task copyReport(type: Copy) { from file("buildDir/reports/my-report.pdf") into file("buildDir/toArchive") }
更加復(fù)雜的拷貝:
task copyPdfReportsForArchiving(type: Copy) { from "buildDir/reports" include "*.pdf" into "buildDir/toArchive" }
當(dāng)然拷貝還有更加復(fù)雜的應(yīng)用。這里就不詳細講解了。
以上就是gradle和maven有哪些區(qū)別的詳細內(nèi)容,更多關(guān)于gradle和maven 區(qū)別的資料請關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
在Spring AOP中代理對象創(chuàng)建的步驟詳解
今天和小伙伴們聊一聊 Spring AOP 中的代理對象是怎么創(chuàng)建出來的,透過這個過程再去熟悉一下 Bean 的創(chuàng)建過程,感興趣的小伙伴跟著小編一起來看看吧2023-08-08Hibernate三種狀態(tài)和Session常用的方法
本文主要介紹了Hibernate三種狀態(tài)和Session常用的方法,具有很好的參考價值,下面跟著小編一起來看下吧2017-03-03Java設(shè)計模式之狀態(tài)模式(State模式)介紹
這篇文章主要介紹了Java設(shè)計模式之狀態(tài)模式(State模式)介紹,本文講解了何時使用狀態(tài)模式、如何使用狀態(tài)模式等內(nèi)容,需要的朋友可以參考下2015-03-03Mybatis如何使用動態(tài)語句實現(xiàn)批量刪除(delete結(jié)合foreach)
這篇文章主要介紹了Mybatis如何使用動態(tài)語句實現(xiàn)批量刪除(delete結(jié)合foreach),具有很好的參考價值,希望對大家有所幫助。如有錯誤或未考慮完全的地方,望不吝賜教2022-03-03Java Swing實現(xiàn)窗體添加背景圖片的2種方法詳解
這篇文章主要介紹了Java Swing實現(xiàn)窗體添加背景圖片的2種方法,結(jié)合實例形式較為詳細的分析了Swing實現(xiàn)窗體添加背景圖片的方法,并總結(jié)分析了Swing重繪中repaint與updateUI的區(qū)別,需要的朋友可以參考下2017-11-11MyBatisPlus3如何向數(shù)據(jù)庫中存入List
本文主要介紹了Mybatis Plus的類型處理器的使用,通過User.java和UserMapper.xml示例進行詳細的解析,并提供了JSON解析器的使用方法,希望通過這篇文章,可以幫助大家更好的理解和掌握Mybatis Plus的類型處理器2024-10-10