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

一、寻找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也定义了构建生命周期,包括编译主代码、处理资源、编译测试代码、执行测试、上传归档等等任务:

Maven、gradle、Ant、Eclipse IDE

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

上一篇:编写代码时清晰至上


下一篇:JAVA 线程池原理,华为Java工程师面试题