Maven、gradle、Ant、Eclipse IDE

Maven、gradle、Ant、Eclipse IDE之间的关系 

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

以为应该不少同窗有和我同样的疑惑，因此分享下。     

      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

 

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 库，能够以下配置：

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

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 文件以下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

apply plugin: 'java'   version: '1.0-SNAPSHOT' group: 'org.opoo'   repositories {   mavenRepo urls: "file:///D:/m2.repo"   //mavenLocal()   //mavenCentral() }   dependencies {     compile group: 'commons-lang', name: 'commons-lang', version: '2.1'     compile group: 'commons-logging', name: 'commons-logging', version: '1.0.4'     testCompile group: 'junit', name: 'junit', version: '4.+' }

相关说明

[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发布版本中。