[Android分享] Maven、gradle、Ant、Eclipse IDE之間的關係
覺得應該很多同學有和我一樣的疑惑，所以分享下。
1.使用github上的開源項目時是不是經常發現有個叫maven的東西？
2.第一次使用Android studio時是不是要下載一個gradle的玩意？
折騰了一天，想導入下github的客戶端源碼。當然現在還沒成功...各種看不懂的錯誤。鬱悶爲什麼他們弄這些高端玩意幹嘛，我們平時eclipse裏面不一樣的好好的開發嗎。
幸好無意間發現網上這篇回答，豁然開朗。
“一般而言.一個比較正規的項目都不會基於IDE 進行構建..一般會用ant, maven, gradle ,
爲什麼不用ide 呢?首先,是ide的選擇,有人喜歡,用vim,eclipse,intellijidea,收費的,免費的.
特別是公開的項目,你用什麼IDE 相當於爲這個IDE 打廣告了..
所以,一般而言都是用構建工具,而不是IDE .實際上各種IDE 也是基於各種構建系統,也正是不同的IDE,它們的構建方式不同,所以要讓不同的IDE間能一起開發,於是需要一個統一的構建工具,只是你平時不關注而已..
扯到構建工具, 一般c/c++ 項目用make,或者 premake. 而java 一般是ant,ivy,gradle,maven,還有直接的shell, 是不是很多沒聽說過呢?
所以,去看開源項目就是長見識的時候了…”
來源：http://www.oschina.net/question/558461_117208
一、尋找gradle的歷程
一開始的時候，我們只有一個工程，所有要用到的jar包都放到工程目錄下面，時間長了，工程越來越大，使用到的jar包也越來越多，難以理解jar之間的依賴關係。再後來我們把舊的工程拆分到不同的工程裏，靠ide來管理工程之間的依賴關係，各工程下的jar包依賴是雜亂的。一段時間後，我們發現用ide來管理項程很不方便，比如不方便脫離ide自動構建，於是我們寫自己的ant腳本。再後來，維護ant腳本變得痛苦，管理jar包更加痛苦。svn能管理源碼的版本，卻不能管理構建出的部署部件的版本。於是我們決定用maven，然而pom.xml的配置實在太繁了！最後，我找到了神器，gradle!
二、爲什麼是gradle?
1. groovy 比 xml好用
Gradle用groovy來做爲build腳本，比xml要易讀易用得多。用過ant的人都知道，要在ant裏面表達一個if分支功能有多麼的麻煩，不直觀。由於gradle的build腳本就是groovy程序，所以做分支循環等非常方便自然。
2. Convention over Configuration 比寫大量ant基礎腳本方便
用ant的時候，要得定義哪裏放源碼，哪裏放jar包，哪裏放編譯出的class文件等等，每個項目都要這樣做，非常麻煩。gradle和maven一樣，都定義了一個默認的目錄結構，只要按要這個默認的規則來做，就不需要多寫一行代碼。而且gradle的目錄的結構規範和maven是一樣的。
3. 支付定義task，比maven靈活
maven可以幫助管理依賴關係，但是要在maven裏實現一個簡單的自定義功能，就很麻煩，要得寫maven插件，而在gradle裏，task是一等公民，可以輕易的添加自己的功能。
4. 靈活的依賴管理
ant沒有依賴管理的功能，都要自己手動做，maven的依賴管理很死板，只能依賴於標準的maven artifact，不能依賴本地的某個jar文件或者其它的源碼。而gradle則可以混合地同時支持這些依賴方法，這樣可以讓舊項目的遷移容易得多。
5. 默認就具有豐富的功能
只要安裝好gradle，默認就支持java項目,war項目，ear項目，做單元測試，生成jar包，上傳jar包到maven服務器，等等功能。一般的項目都已經夠用了。
MAVEN項目秒變Gradle項目
切換到你maven項目目錄
然後執行
gradle setupBuild --type pom
回車之後
你的maven項目已經秒變gradle項目
要求版本：gradle1.7
Maven實戰（六）——Gradle，構建工具的未來？
Maven面臨的挑戰
軟件行業新舊交替的速度之快往往令人咂舌，不用多少時間，你就會發現曾經大紅大紫的技術已經成爲了昨日黃花，當然，Maven也不會例外。雖然目前它基本上是Java構建的事實標準，但我們也能看到新興的工具在涌現，比如基於Goovy的Gradle，而去年Hibernate宣佈從Maven遷移至Gradle這一事件更是吸引了不少眼球。在此之前，我也聽到了不少對Maven的抱怨，包括XML的繁冗，不夠靈活，學習曲線陡峭等等。那Gradle是否能夠在繼承 Maven優點的基礎上，克服這些缺點呢？帶着這個疑問，我開始閱讀Gradle的文檔並嘗試着將一個基於Maven的項目轉成用Gradle構建，本文所要講述大概就是這樣的一個體驗。需要注意的是，本文完全是基於Maven的角度來看Gradle的，因此對於Ant用戶來說，視角肯定會大有不同。
Gradle初體驗
Gradle的安裝非常方便，下載ZIP包，解壓到本地目錄，設置 GRADLE_HOME 環境變量並將 GRADLE_HOME/bin 加到 PATH 環境變量中，安裝就完成了。用戶可以運行gradle -v命令驗證安裝，這些初始的步驟和Maven沒什麼兩樣。Gradle目前的版本是1.0-milestone-1，根據其Wiki上的Roadmap，在1.0正式版發佈之前，還至少會有3個里程碑版本，而1.0的發佈日期最快也不會早於6月份。而正是這樣一個看起來似乎還不怎麼成熟的項目，卻有着讓很多成熟項目都汗顏的文檔，其包括了安裝指南、基本教程、以及一份近300頁的全面用戶指南。這對於用戶來說是非常友好的，同時也說明了Gradle的開發者對這個項目非常有信心，要知道編寫並維護文檔可不是件輕鬆的工作，對於Gradle這樣未來仍可能發生很大變動的項目來說尤爲如此。
類似於Maven的pom.xml文件，每個Gradle項目都需要有一個對應的build.gradle文件，該文件定義一些任務（task）來完成構建工作，當然，每個任務是可配置的，任務之間也可以依賴，用戶亦能配置缺省任務，就像這樣：
defaultTasks 'taskB'
task taskA << {
println "i'm task A"
}
task taskB << {
println "i'm task B, and I depend on " + taskA.name
}
taskB.dependsOn taskA運行命令$ gradle -q之後（參數q讓Gradle不要打印錯誤之外的日誌），就能看到如下的預期輸出：
i'm task A i'm task B, and I depend on taskA
這不是和Ant如出一轍麼？的確是這樣，這種“任務”的概念與用法與Ant及其相似。Ant任務是Gradle世界的第一公民，Gradle對Ant做了很好的集成。除此之外，由於Gradle使用的Grovvy腳本較XML更爲靈活，因此，即使我自己不是Ant用戶，我也仍然覺得Ant用戶會喜歡上Gradle。
依賴管理和集成Maven倉庫
我們知道依賴管理、倉庫、約定優於配置等概念是Maven的核心內容，拋開其實現是否最優不談，概念本身沒什麼問題，並且已經被廣泛學習和接受。那Gradle實現了這些優秀概念了麼？答案是肯定的。
先看依賴管理，我有一個簡單的項目依賴於一些第三方類庫包括SpringFramework、JUnit、Kaptcha等等。原來的Maven POM配置大概是這樣的（篇幅關係，省略了部分父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')
}注意配置從原來的28行縮減至7行！這還不算我省略的一些父POM配置。依賴的groupId、artifactId、 version，scope甚至是classfier，一點都不少。較之於Maven或者Ant的XML配置腳本，Gradle使用的Grovvy腳本殺傷力太大了，愛美之心，人皆有之，相比於七旬老婦鬆鬆垮垮的皺紋，大家肯定都喜歡少女緊緻的臉蛋，XML就是那老婦的皺紋。
關於Gradle的依賴管理起初我有一點擔心，就是它是否有傳遞性依賴的機制呢？經過文檔閱讀和實際試驗後，這個疑慮打消了，Gradle能夠解析現有的Maven POM或者Ivy的XML配置，從而得到傳遞性依賴的信息，並且引入到當前項目中，這實在是一個聰明的做法。在此基礎上，它也支持排除傳遞性依賴或者乾脆關閉傳遞性依賴，其中第二點是Maven所不具備的特性。
自動化依賴管理的基石是倉庫，Maven中央倉庫已經成爲了Java開發者不可或缺的資源，Gradle既然有依賴管理，那必然也得用到倉庫，這當然也包括了Maven中央倉庫，就像這樣：
repositories {
mavenLocal()
mavenCentral()
mavenRepo urls: "http://repository.sonatype.org/content/groups/forge/"
}這段代碼幾乎不用解釋，就是在Gradle中配置使用Maven本地倉庫、中央倉庫、以及自定義地址倉庫。在我實際構建項目的時候，能看到終端打印的下載信息，下載後的文件被存儲在USER_HOME/.gradle/cache/ 目錄下供項目使用，這種實現的方法與Maven又是及其類似了，可以說Gradle不僅最大限度的繼承Maven的很多理念，倉庫資源也是直接拿來用。
Gradle項目使用Maven項目生成的資源已經不是個問題了，接着需要反過來考慮，Maven用戶是否能夠使用 Gradle生成的資源呢？或者更簡單點問，Gradle項目生成的構件是否可以發佈到Maven倉庫中供人使用呢？這一點非常重要，因爲如果做不到這一點，你可能就會丟失大量的用戶。幸運的是Gradle再次給出了令人滿意的答案。使用Gradle的Maven Plugin，用戶就可以輕鬆地將項目構件上傳到Maven倉庫中：
apply plugin: 'maven'
...
uploadArchives {
repositories.mavenDeployer {
repository(url: "http://localhost:8088/nexus/content/repositories/snapshots/") {
authentication(userName: "admin", password: "admin123")
pom.groupId = "com.juvenxu"
pom.artifactId = "account-captcha"
}
}
}在上傳的過程中，Gradle能夠基於build.gradle生成對應的Maven POM文件，用戶可以自行配置POM信息，比如這裏的groupId和artifactId，而諸如依賴配置這樣的內容，Gradle是會自動幫你進行轉換的。由於Maven項目之間依賴交互的直接途徑就是倉庫，而Gradle既能夠使用Maven倉庫，也能以Maven的格式將自己的內容發佈到倉庫中，因此從技術角度來說，即使在一個基於Maven的大環境中，局部使用Gradle也幾乎不會是一個問題。
約定優於配置
如同Ant一般，Gradle給了用戶足夠的自由去定義自己的任務，不過同時Gradle也提供了類似Maven的約定由於配置方式，這是通過Gradle的Java Plugin實現的，從文檔上看，Gradle是推薦這種方式的。Java Plugin定義了與Maven完全一致的項目佈局：
src/main/java
src/main/resources
src/test/java
src/test/resources
區別在於，使用Groovy自定義項目佈局更加的方便：
sourceSets {
main {
java {
srcDir 'src/java'
}
resources {
srcDir 'src/resources'
}
}
}Gradle Java Plugin也定義了構建生命週期，包括編譯主代碼、處理資源、編譯測試代碼、執行測試、上傳歸檔等等任務：
Figure 1. Gradle的構建生命週期
相對於Maven完全線性的生命週期，Gradle的構建生命週期略微複雜，不過也更爲靈活，例如jar這個任務是用來打包的，它不像Maven那樣依賴於執行測試的test任務，類似的，從圖中可以看到，一個最終的build任務也沒有依賴於uploadArchives任務。這個生命週期並沒有將用戶限制得很死，舉個例子，我希望每次build都發布 SNAPSHOT版本到Maven倉庫中，而且我只想使用最簡單的$ gradle clean build命令，那只需要添加一行任務依賴配置即可：
build.dependsOn 'uploadArchives'
由於Gradle完全是基於靈活的任務模型，因此很多事情包括覆蓋現有任務，跳過任務都非常易於實現。而這些事情，在Maven的世界中，實現起來就比較的麻煩，或者說Maven壓根就不希望用戶這麼做。
小結
一番體驗下來，Gradle給我最大的感覺是兩點。其一是簡潔，基於Groovy的緊湊腳本實在讓人愛不釋手，在表述意圖方面也沒有什麼不清晰的地方。其二是靈活，各種在Maven中難以下手的事情，在Gradle就是小菜一碟，比如修改現有的構建生命週期，幾行配置就完成了，同樣的事情，在Maven中你必須編寫一個插件，那對於一個剛入門的用戶來說，沒個一兩天幾乎是不可能完成的任務。
不過即使如此，Gradle在未來能否取代Maven，在我看來也還是個未知數。它的一大障礙就是Grovvy，幾乎所有 Java開發者都熟悉XML，可又有幾個人瞭解Groovy呢？學習成本這道坎是很難跨越的，很多人抵制Maven就是因爲學起來不容易，你現在讓因爲一個構建工具學習一門新語言（即使這門語言和Java非常接近），那得到冷淡的回覆幾乎是必然的事情。Gradle的另外一個問題就是它太靈活了，雖然它支持約定優於配置，不過從本文你也看到了，破壞約定是多麼容易的事情。人都喜歡自由，愛自定義，覺得自己的需求是多麼的特別，可事實上，從Maven的流行來看，幾乎95%以上的情況你不需要自行擴展，如果你這麼做了，只會讓構建變得難以理解。從這個角度來看，自由是把雙刃劍，Gradle給了你足夠的自由，約定優於配置只是它的一個選項而已，這初看起來很誘人，卻也可能使其重蹈Ant的覆轍。Maven在Ant的基礎上引入了依賴管理、倉庫以及約定優於配置等概念，是一個很大的進步，不過在我現在看來，Gradle並沒有引入新的概念，給我感覺它是一個結合Ant和Maven理念的優秀實現。
如果你瞭解Groovy，也理解Maven的約定優於配置，那試試Gradle倒也不錯，尤其是它幾乎能和現有的Maven系統無縫集成，而且你也能享受到簡潔帶來的極大樂趣。其實說到簡潔，也許在不久的將來Maven用戶也能直接享受到，Polyglot Maven在這方面已經做了不少工作。本文完全基於Maven的視角介紹Gradle這一構建工具的新秀，不過限於篇幅原因，無法深入Gradle的方方面面，例如Gradle也支持多模塊構建，它提供了GUI操作界面，支持Grovvy（理所當然）和Scala項目等等。有興趣的讀者可以自行進一步瞭解。
關於作者
許曉斌（Juven Xu），國內社區公認的Maven技術專家、Maven中文用戶組創始人、Maven技術的先驅和積極推動者，著有《Maven實戰》一書。對Maven有深刻的認識，實戰經驗豐富，不僅撰寫了大量關於Maven的技術文章，而且還翻譯了開源書籍《Maven權威指南》，對Maven技術在國內的普及和發展做出了很大的貢獻。就職於Maven之父的公司，負責維護Maven中央倉庫，是Maven倉庫管理器Nexus（著名開源軟件）的核心開發者之一，曾多次受邀到淘寶等大型企業開展Maven方面的培訓。此外，他還是開源技術的積極倡導者和推動者，擅長Java開發和敏捷開發實踐。他的個人網站是：http://www.juvenxu.com。
==========================
Gradle 初體驗
Gradle 是一個基於 Groovy 的構建工具，吸取了 Maven 的一些有點，還可以直接使用 Maven 庫，所有大有取代 Maven 的架勢[4]。
Gradle 的官方網站是 http://www.gradle.org/，在這裏下載 zip 包，解壓，設置環境變量 GRADLE_HOME 並加到 path 中即可。詳情請閱讀 用戶手冊 。
Gradle 的主要配置文件是 build.gradle，如果要使用 Maven 庫，可以如下配置：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
|
其中有必要說說 mavenLocal()，能不能用 Maven 本地庫也是筆者最關心的特性之一。
經實踐，發現直接使用 mavenLocal() 時，gradle 會查找 Maven 配置文件 ${user.home}/.m2/settings.xml 來定位本地 Maven 庫的路徑，如果沒有找到該文件，則默認本地庫路徑爲 ${user.home}/.m2/repository，而筆者的 Maven 配置文件在 $M2_HOME/conf/settings.xml ，gradle 竟然不能讀取到這個配置文件。
這個問題已經作爲一個Improvement（#GRADLE-1900 [5]）被提出，並顯示在 1.0-milestone-9 版本中已經修正，而使用的1.0正式版時，竟然還有這個問題，真是相當詭異。
既然不能直接使用 mavenLocal()，就必須做一些變通，筆者最終測試用的 build.gradle 文件如下：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|
相關說明
[1] InfoQ: Gradle，構建工具的未來？http://www.infoq.com/cn/news/2011/04/xxb-maven-6-gradle
[2] Gradle 使用 Maven 本地庫 http://issues.gradle.org/browse/GRADLE-1900
日常運用編輯
功能
gradle對多工程的構建支持很出色，工程依賴是gradle的第一公民。
gradle支持局部構建。
支持多方式依賴管理：包括從maven遠程倉庫、nexus私服、ivy倉庫以及本地文件系統的jars或者dirs
gradle是第一個構建集成工具（the first build integration tool），與ant、maven、ivy有良好的相容相關性。
輕鬆遷移：gradle適用於任何結構的工程（Gradle can adapt to any structure you have.）。你可以在同一個開發平臺平行構建原工程和gradle工程。通常要求寫相關測試，以保證開發的插件的相似性，這種遷移可以減少破壞性，儘可能的可靠。這也是重構的最佳實踐。
gradle的整體設計是以作爲一種語言爲導向的，而非成爲一個嚴格死板的框架。
免費開源
gradle提供了什麼
1.一種可切換的，像maven一樣的基於約定的構建框架，卻又從不鎖住你（約定優於配置）
Switchable, build-by-convention frameworks a la Maven. But we never lock you in!
2. 強大的支持多工程的構建
3. 強大的依賴管理（基於Apache Ivy），提供最大的便利去構建你的工程
Language for dependency based programming
4. 全力支持已有的Maven或者Ivy倉庫基礎建設
5. 支持傳遞性依賴管理，在不需要遠程倉庫和pom.xml和ivy配置文件的前提下
6 基於groovy腳本構建，其build腳本使用groovy語言編寫
7 具有廣泛的領域模型支持你的構建A rich domain model for describing your build.
2開發工具編輯
1 IntelliJ IDEA 當前最新版本13.0.1
2 Eclipse
2.1 習慣使用eclipse的同學，也可以使用eclipse，建議版本eclipse-jee-juno-SR1-win32，然後安裝gradle和groovy插件即可。
3 Android Studio
3.1 STS（Springsource tool suite）當前最新版本3.4.0.RELEASE
4NetBeans 目前尚未支持Gradle
NetBeans子項目Gradle for NetBeans IDE 是Gradle的支持項目，尚未出現在NetBeans發佈版本中。