Build tool

what：

Build tool（構建工具）是從源代碼自動建立可執行應用程序的程序。構建包括將代碼編譯，連接和打包成可用或可執行的形式。在小項目中，開發人員一般會手動調用構建過程。這對於較大的項目來講是不實際的，在這些項目中，很難跟蹤須要構建的內容，構建過程當中的順序和依賴關係。使用自動化工具可使構建過程更加一致

how：

一、靈活性

谷歌選擇Gradle做爲Android的官方構建工具 ; 不是由於構建腳本是代碼，而是由於Gradle以最基本的方式可擴展的方式建模。Gradle的模型還容許它用於C / C ++的本地開發，而且能夠擴展到涵蓋任何生態系統。例如，Gradle的設計考慮了使用其Tooling API嵌入。

Gradle和Maven都提供了約定優於配置。然而，Maven提供了一個很是嚴格的模型，使定製變得乏味，有時甚至是不可能的。雖然這可使任何給定的Maven構建更容易理解，但只要您沒有任何特殊要求，它也會使它不適合許多自動化問題。另外一方面，Gradle是在充分受權和負責任的用戶的基礎上構建的

二、性能

縮短構建時間是最快速發貨的最直接方式之一。Gradle和Maven都採用某種形式的並行項目構建和並行依賴性解析。最大的區別是Gradle的工做避免和增量機制。使Gradle比Maven快得多的前3個功能是：

• 增量 - Gradle經過跟蹤任務的輸入和輸出並僅運行必要的操做來避免工做，而且只處理在可能的狀況下更改的文件。
• 構建緩存 - 使用相同的輸入（包括計算機之間）重用任何其餘Gradle構建的構建輸出。
• Gradle守護進程 - 一種長期存在的進程，可將構建信息保持在內存中「熱」。

在Gradle與Maven性能比較中，這些和更多性能特性使Gradle在幾乎每種狀況下的速度至少快兩倍（使用構建緩存的大型構建速度快100倍）

三、用戶體驗

Maven的任期較長意味着它經過IDE的支持對許多用戶來講更好。可是，Gradle的IDE支持繼續快速提高。例如，Gradle如今有一個基於Kotlin的DSL，能夠提供更好的IDE體驗。Gradle團隊正在與IDE製造商合做，以更好地提供編輯支持 - 敬請關注更新。

雖然IDE很重要，可是大量用戶更喜歡經過命令行界面執行構建操做。Gradle提供了一個現代CLI，具備可發現功能，如「gradle tasks」，以及改進的日誌記錄和命令行完成。

最後，Gradle提供了一個基於Web的交互式UI，用於調試和優化構建：構建掃描。這些也能夠在本地託管，以容許組織收集構建歷史記錄並進行趨勢分析，比較構建以進行調試或優化構建時間。

四、依賴管理

兩個構建系統都提供了內置功能，能夠解析來自可配置存儲庫的依賴關係。二者都可以在本地緩存依賴項並並行下載它們。

做爲庫使用者，Maven容許覆蓋依賴項，但僅限於版本。Gradle提供可自定義的依賴項選擇和替換規則，能夠聲明一次並在項目範圍內處理不須要的依賴項。此替換機制使Gradle可以一塊兒構建多個源項目以建立複合構建。

Maven具備不多的內置依賴範圍，它們在常見場景中強制使用笨拙的模塊架構，例如使用測試夾具或代碼生成。例如，單元測試和集成測試之間沒有分離。Gradle容許自定義依賴項範圍，從而提供更好的建模和更快的構建。

做爲庫生產者，Gradle容許生產者聲明`api`和`implementation`依賴關係，以防止不須要的庫泄漏到消費者的類路徑中。Maven容許發佈者經過可選的依賴項提供

總的來講，Gradle和Maven都是項目自動構建工具，編譯源代碼只是整個過程的一個方面，更重要的是，你要把你的軟件發佈到生產環境中來產生商業價值，因此，你要運行測試，構建分佈、分析代碼質量、甚至爲不一樣目標環境提供不一樣版本，而後部署。整個過程進行自動化操做是頗有必要的。

整個過程能夠分紅如下幾個步驟：
編譯源代碼
運行單元測試和集成測試
執行靜態代碼分析、生成分析報告
建立發佈版本
部署到目標環境
部署傳遞過程
執行冒煙測試和自動功能測試
若是你手工去執行每個步驟無疑效率比較低並且容易出錯，有了自動化構建你只須要自定義你的構建邏輯，剩下的事情交給工具去完成。

雖然二者都是項目工具，可是maven如今已是行業標準，Gradle是後起之秀，不少人對他的瞭解都是從android studio中獲得的，Gradle拋棄了Maven的基於XML的繁瑣配置，衆所周知XML的閱讀體驗比較差，對於機器來講雖然容易識別，但畢竟是由人去維護的。取而代之的是Gradle採用了領域特定語言Groovy的配置，大大簡化了構建代碼的行數，好比在Maven中你要引入一個依賴：

<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')
}

注意配置從原來的28行縮減至7行！這還不算我省略的一些父POM配置。依賴的groupId、artifactId、 version，scope甚至是classfier，一點都很多。較之於Maven或者Ant的XML配置腳本，Gradle使用的Grovvy腳本殺傷力太大了，愛漂亮之心，人皆有之，相比於七旬老婦鬆鬆垮垮的皺紋，你們確定都喜歡少女緊緻的臉蛋，XML就是那老婦的皺紋。

Gradle給我最大的有點是兩點。其一是簡潔，基於Groovy的緊湊腳本實在讓人愛不釋手，在表述意圖方面也沒有什麼不清晰的地方。其二是靈活，各類在Maven中難如下手的事情，在Gradle就是小菜一碟，好比修改現有的構建生命週期，幾行配置就完成了，一樣的事情，在Maven中你必須編寫一個插件，那對於一個剛入門的用戶來講，沒個一兩天幾乎是不可能完成的任務

why：

git作版本控制，不管是否使用maven都行。
maven用來構建，能夠經過添加maven repository（Maven倉庫）中的依賴，減小項目中的jar數量，而且大的項目中模塊交叉引用也可以用它很好地解決。
二者配合的方式，經過.gitignore文件中添加jar、target目錄，能夠避免將這些二進制文件、自動生成的文件加入到版本庫中，從而減少版本庫的大小，縮短同步時間。其餘人同步以後，只須要執行maven命令，就可以自動從repo裏面下載依賴，按照依賴樹自底而上構建內部交叉依賴。
簡單來講，maven讓git不須要同步沒必要要的第三方庫和自動生成的class、jar文件，並能夠額外同步項目jdk版本等項目設置，標準化構建流程；git只是一個CVS工具，換成SVN、Mercurial也均可以。

可是，Maven有如下優勢，

Maven是一個構建工具,服務與構建.使用Maven配置好項目後,輸入簡單的命令,如:mvn clean install,Maven會幫咱們處理那些繁瑣的任務.
Maven是跨平臺的.
Maven最大化的消除了構建的重複.
Maven能夠幫助咱們標準化構建過程.全部的項目都是簡單一致的,簡化了學習成本.
總之,Maven做爲一個構建工具,不只幫咱們自動化構建,還能抽象構建過程,提供構建任務實現.他跨平臺,對外提供一致的操做接口,這一切足以使他成爲優秀的,流行的構建工具.
可是Maven不只是構建工具,他仍是一個依賴管理工具和項目信息管理工具.他還提供了中央倉庫,能幫咱們自動下載構件.

 

Gradle和Maven都是項目自動構建工具，編譯源代碼只是整個過程的一個方面，更重要的是，你要把你的軟件發佈到生產環境中來產生商業價值，因此，你要運行測試，構建分佈、分析代碼質量、甚至爲不一樣目標環境提供不一樣版本，而後部署。整個過程進行自動化操做是頗有必要的。整個過程能夠分紅如下幾個步驟：編譯源代碼運行單元測試和集成測試執行靜態代碼分析、生成分析報告建立發佈版本部署到目標環境部署傳遞過程執行冒煙測試和自動功能測試若是你手工去執行每個步驟無疑效率比較低並且容易出錯，有了自動化構建你只須要自定義你的構建邏輯，剩下的事情交給工具去完成。雖然二者都是項目工具，可是maven如今已是行業標準，Gradle是後起之秀，不少人對他的瞭解都是從android studio中獲得的，Gradle拋棄了Maven的基於XML的繁瑣配置，衆所周知XML的閱讀體驗比較差，對於機器來講雖然容易識別，但畢竟是由人去維護的。取而代之的是Gradle採用了領域特定語言Groovy的配置，大大簡化了構建代碼的行數，好比在Maven中你要引入一個依賴：<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')}注意配置從原來的28行縮減至7行！這還不算我省略的一些父POM配置。依賴的groupId、artifactId、 version，scope甚至是classfier，一點都很多。較之於Maven或者Ant的XML配置腳本，Gradle使用的Grovvy腳本殺傷力太大了，愛漂亮之心，人皆有之，相比於七旬老婦鬆鬆垮垮的皺紋，你們確定都喜歡少女緊緻的臉蛋，XML就是那老婦的皺紋。Gradle給我最大的有點是兩點。其一是簡潔，基於Groovy的緊湊腳本實在讓人愛不釋手，在表述意圖方面也沒有什麼不清晰的地方。其二是靈活，各類在Maven中難如下手的事情，在Gradle就是小菜一碟，好比修改現有的構建生命週期，幾行配置就完成了，一樣的事情，在Maven中你必須編寫一個插件，那對於一個剛入門的用戶來講，沒個一兩天幾乎是不可能完成的任務