Maven、gradle、Ant、Eclipse IDE

時間 2019-11-17

標籤 maven gradle ant eclipse ide 欄目 Maven 简体版

原文原文鏈接

Maven、gradle、Ant、Eclipse IDE之間的關係 html

http://wenku.baidu.com/view/d33208810912a21615792910.html?from=searchjava

以爲應該不少同窗有和我同樣的疑惑，因此分享下。 c++

1.使用github上的開源項目時是否是常常發現有個叫maven的東西？git

2.第一次使用Android studio時是否是要下載一個gradle的玩意？github

折騰了一天，想導入下github的客戶端源碼。固然如今還沒成功...各類看不懂的錯誤。鬱悶爲何他們弄這些高端玩意幹嗎，咱們平時eclipse裏面不同的好好的開發嗎。spring

幸虧無心間發現網上這篇回答，豁然開朗。shell

「通常而言.一個比較正規的項目都不會基於IDE 進行構建..通常會用ant, maven, gradle ,
爲何不用ide 呢?首先,是ide的選擇,有人喜歡,用vim,eclipse,intellijidea,收費的,免費的.vim

特別是公開的項目,你用什麼IDE 至關於爲這個IDE 打廣告了..服務器

因此,通常而言都是用構建工具,而不是IDE .實際上各類IDE 也是基於各類構建系統,也正是不一樣的IDE,它們的構建方式不一樣,因此要讓不一樣的IDE間能一塊兒開發,因而須要一個統一的構建工具,只是你平時不關注而已..app

扯到構建工具, 通常c/c++ 項目用make,或者 premake. 而java 通常是ant,ivy,gradle,maven,還有直接的shell, 是否是不少沒據說過呢?

因此,去看開源項目就是長見識的時候了…」

來源：http://www.oschina.net/question/558461_117208

1、尋找gradle的歷程

一開始的時候，咱們只有一個工程，全部要用到的jar包都放到工程目錄下面，時間長了，工程愈來愈大，使用到的jar包也愈來愈多，難以理解jar之間的依賴關係。再後來咱們把舊的工程拆分到不一樣的工程裏，靠ide來管理工程之間的依賴關係，各工程下的jar包依賴是雜亂的。一段時間後，咱們發現用ide來管理項程很不方便，好比不方便脫離ide自動構建，因而咱們寫本身的ant腳本。再後來，維護ant腳本變得痛苦，管理jar包更加痛苦。svn能管理源碼的版本，卻不能管理構建出的部署部件的版本。因而咱們決定用maven，然而pom.xml的配置實在太繁了！最後，我找到了神器，gradle!

2、爲何是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 庫，能夠以下配置：

repositories {

//Maven中心庫(http://repo1.maven.org/maven2)

mavenCentral()

//本地庫，local repository(${user.home}/.m2/repository)

mavenLocal()

//指定庫

maven {

url "http://repo.mycompany.com/maven2"

}

//指定庫

mavenRepo name: reponame', url: "http://repo.mycompany.com/maven2"

//指定庫

maven {

// Look for POMs and artifacts, such as JARs, here

url "http://repo2.mycompany.com/maven2"

// Look for artifacts here if not found at the above location

artifactUrls "http://repo.mycompany.com/jars"

artifactUrls "http://repo.mycompany.com/jars2"

}

//帶認證的庫

maven {

credentials {

username 'user'

password 'password'

}

url "http://repo.mycompany.com/maven2"

}

其中有必要說說 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 文件以下：