Gradle深刻与实战(转)

转自：NO　END FOR LEARNING http://benweizhu.github.io/blog/2015/01/31/deep-into-gradle-in-action-1/

什么是构建工具?

一个可编程的工具，可以以可执行和有序的任务来表达知足须要的自动化过程。

以Java为例，要获得一个简单可运行的Jar文件，须要下面几步：

1.编译源代码
2.运行测试（前提是你有测试） 3.拷贝Class文件到目标目录
4.打包Class文件为Jar文件

这是一个完整的可自动化的过程，在没有构建工具以前，是由谁来作？IDE。一个强大的IDE，以上的步骤都只须要按几个按钮，这让开发人员的生活变得很美好，彻底集中在写出优秀的代码。

如今，原本整个开发过程只须要你一我的，随着任务的难度和复杂度的加重，你的团队从一我的变成了3我的或者更多。这时，你确定会须要代码集成，这个问题好解决，使用版本控制，不管是中心式的SVN仍是分布式的Git，总之能够既能够解决版本问题，也解决代码集成的问题。

这种状况下，在没有自动化构建时，你确定会遇到下面几个问题： 
1.在个人机器上能够跑 
2.从版本控制check out代码，发现编译不过，有人少提交了代码文件
3.有我的提交代码时没跑测试，致使其余人check out代码后，测试跑不过
4.版本发布时，由一我的来check out全部代码，在他本身的机器上编译打包，结果部署到服务器上运行不了
…

致使上面这些问题出现的缘由都有两个特色： 
1.手动介入
2.重复任务

开发人员要关注的应该是编写实现功能的代码，至于编译编译代码，拷贝文件，运行测试等一切重复和可自动化的事情都应该交给机器去作，由于人是容易犯错的。

Java世界的构建工具

在Java的世界里，目前在被使用的经常使用构建工具备三个：Ant，Maven，Gradle。

Ant的核心是由Java编写，采用XML做为构建脚本，这样就容许你在任何环境下，运行构建。Ant基于任务链思想，任务之间定义依赖，造成前后顺序。缺点是使用XML定义构建脚本，致使脚本臃肿，Ant自身没有为项目构建提供指导，致使每一个build脚本都不同，开发人员对于每一个项目都须要去熟悉脚本内容，没有提供在Ant生态环境内的依赖管理工具。

Maven团队意识到Ant的缺陷，采用标准的项目布局，和统一的生命周期，采用约定因为配置的思想，减小构建脚本须要的编写内容，活跃的社区，能够方便找到合适的插件，强大的依赖管理工具。缺点是采用默认的结构和生命周期，太过限制，编写插件扩展麻烦，XML做为构建脚本。

若是有一个构建工具能够折中，同时拥有Ant和Maven的优势，是否是很爽？告诉你有，那就是Gradle。

Gradle

基于Groovy的DSL，提供声明式的构建语言 
采用标准的项目布局，但拥有彻底的可配置性，就是能够改 
经过插件，提供默认的构建生命周期，也能够本身定义任务，单独运行任务，定义任务间的依赖 
强大的依赖管理工具，与Maven和Ivy仓库结合
与Ant天生兼容，有效的重用Ant的任务
多种实现插件的方式，强大的官方插件库
从构建级别，支持从Ant或者Maven的逐步迁移
经过包装器，无缝的在各个平台运行

看一个超级简单的例子：

若是你的项目采用标准的Maven布局（Java世界的标准布局）

1 2 3 4 5 6 7 8 9 10

src {//目录结构而已，不是代码 main { java resources } test { java resources } }

在项目根目录下，建立一个build.gradle，这个是Gradle的构建脚本文件，就和build.xml，POM.xml道理同样。

那么你要实现Java的编译，测试，拷贝class到目标目录，打包Jar文件等，只须要在构建脚本中，使用下面一句话，使用Java插件。

1	apply plugin: 'java'

而后运行gradle build。

下一篇，咱们深刻到实战学习Java插件的使用和依赖管理，让你快速开始Java应用开发。

没有介绍Gradle的基础知识，直接开始实战，目的是为了更快的让你们开始使用Gradle作构建，快速上手，当须要实现的自动化需求更复杂时，在深刻学习基础知识。

这一篇，咱们直接开始Java插件的使用。

应用Java插件

Gradle是一个通用构建工具，也就是说，它不单是为Java而生。好比，还能够作Groovy，Scala的构建。这取决于你使用什么样的插件。

大部分Java项目的基本步骤都很是相似，编译Java源代码，运行单元测试，拷贝生成的class文件到目标目录，打包Jar文件（或者War包，Ear包），而这些重复且约定俗成的任务，若是能够不用写一行构建代码就实现，是多么的棒！Maven就作到这一点，采用约定因为配置的思想，预先定义经常使用的任务，并定义它们的执行顺序。

Gradle吸取了Maven的这个优势，经过插件，实现预约义任务和任务之间依赖关系的导入，这样就能够在一行代码都不写的状况下（若是应用插件，你以为也算一行的话，那就写一行吧），直接使用已经定义的任务。

1	apply plugin: 'java'

SourceSet和项目布局

就和Maven同样，在默认的状况下，项目的目录结构是固定的Java世界的标准项目目录布局，只不过Maven的不能够改，可是Gradle能够改。

1 2 3 4 5 6 7 8 9 10

src {//目录结构而已，不是代码 main { java resources } test { java resources } }

Java插件引入了一个概念叫作SourceSets，它表明了一组源文件，经过修改SourceSets中的属性，能够指定哪些源文件（或文件夹下的源文件）要被编译，哪些源文件要被排除。Gradle就是经过它实现Java项目的布局定义。

Java插件默认实现了两个SourceSet，main和test。每一个SourceSet都提供了一系列的属性，经过这些属性，能够定义该SourceSet所包含的源文件。好比，java.srcDirs，resources.srcDirs。Java插件中定义的其余任务，就根据main和test的这两个SourceSet的定义来寻找产品代码和测试代码等。

在构建脚本中，怎么样定义或者修改SourceSet呢？Gradle提供了一系列的DSL，可让你方便的定义或者修改配置。好比，sourceSets的DSL。

1 2 3 4 5 6 7 8 9 10

sourceSets { main { java { srcDir 'src/java' } resources { srcDir 'src/resources' } } }

上面的这个例子，在sourceSets中，修改了Java插件中已经定义的SourceSet main，修改了它的java.srcDir和resources.srcDir。因而，项目的目录结构就改变了。

改变Java插件中预约义的项目目录结构，不是咱们最终的目的，由于它是目前Java世界，标准的项目布局，或者说你们都遵照的项目布局。

sourceSets最主要的做用是增长新的目录约定，好比，你想要定义一个新的SourceSet来管理集成测试的源文件，这样能够将单元测试和集成测试分开管理。

至于，关于具体如何为集成测试写一个新的SourceSet会在后面介绍依赖管理时举例说明。

Java插件提供的任务

Java插件提供了一系列的任务给你使用，包括编译，运行测试，打包等等。当你在项目中应用Java插件时，就已经将这些任务集成到你的项目中了。

在命令行中，运行gradle tasks命令，能够查看当前项目下主要的task。

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

Build tasks assemble - Assembles the outputs of this project. build - Assembles and tests this project. buildDependents - Assembles and tests this project and all projects that depend on it. buildNeeded - Assembles and tests this project and all projects it depends on. clean - Deletes the build directory. jar - Assembles a jar archive containing the main classes. Documentation tasks javadoc - Generates Javadoc API documentation for the main source code. Verification tasks check - Runs all checks. test - Runs the unit tests.

你能够对比Java插件应用前和应用后该命令的输出，Java插件提供的任务有不少，至于每一个任务是作什么，这里就不赘述了。

Java插件除了为你预约义这些任务，该预约义了这些任务之间的依赖关系。以下图：

你也能够经过命令gradle tasks –all来查看每一个task各自有什么依赖。

固然，这里仍是重点提下，Java插件中四个重要和经常使用的任务，assemble，check，build，clean。

assemble 
All archive tasks in the project, including jar. Some plugins add additional archive tasks to the project. 
check 
All verification tasks in the project, including test. Some plugins add additional verification tasks to the project. 
build 
check and assemble 
clean 
Deletes the project build directory.

assemble被用来产生Jar文件，输出目录在build/libs下。

check用来运行全部的验收任务，包括test任务，以及其余验收任务，好比checkstyle。

Tips：在命令行中运行单个测试

JAVA插件中的test任务提供了一个filter属性，能够帮助指定运行test任务时，什么测试源文件要包含，什么要排除。

1 2 3 4 5 6 7 8 9 10 11 12

test { filter { //include specific method in any of the tests includeTestsMatching "*UiCheck" //include all tests from package includeTestsMatching "org.gradle.internal.*" //include all integration tests includeTestsMatching "*IntegTest" } }

固然通常状况下，你不会这么去作。

但重点是，你能够经过命令行传递的参数来指定这个matching规则，这样你就能够经过命令行来指定跑某一类测试，或者单个测试。你必定遇到过，某个测试在命令行中能够运行，在IDE中不能运行，或者反过来。这时，你能够不会想要跑所有的测试来验证某一个测试。因而，你就能够经过命令行来运行某一个测试：

1 2	gradle test --tests org.gradle.SomeTest.someSpecificFeature gradle test --tests *IntegTest

到目前为止，你已经了解了Java插件提供的一些核心功能和有用小技巧。虽然还未涉及到Jar任务和uploadfile任务（这些任务当须要时，再去看就好了），可是就启动项目而言，对Java插件的使用所须要了解的知识已经足够了。

下一节，讲解依赖管理

大部分的项目都不是自包含的，也就是说，须要使用到其余项目的构建结果，好比一些Jar文件。它们做为输入文件，必须存在于项目的ClassPath下，程序才能编译和运行。这些输入文件有一个很表意的名字，叫作依赖。

Gradle容许你告诉它项目的依赖是什么，而后它就会负责找到这些依赖。这些依赖会从Maven或者Ivy的远程仓库下载下来（大部分状况），并缓存在本地的某个路径，这个过程叫作依赖解析。

Maven和Gradle同样也提供了相似的功能，而Ant没有，你只能告诉Ant依赖文件的相对或者绝对路径，让它去加载。

经常一个依赖本身也存在依赖，咱们称为传递依赖，依赖管理工具又具备解析传递依赖的能力。

Gradle的依赖管理

那么如何在Gradle中定义依赖呢？看个最简单的例子。

1 2 3 4 5 6 7 8 9

apply plugin: 'java' repositories { mavenCentral() } dependencies { testCompile 'junit:junit:4.11'// testCompile group: 'junit', name: 'junit', version: '4.11' }

项目使用了Java的插件，在repositories块中告诉Gradle使用maven的远程仓库做为依赖下载地址，在dependencies块定义了一个junit的依赖，并说明了分组(Maven中的Scope)，后面注释中有一个表意更完整的依赖定义，说明了依赖声明使用的三个坐标group，name，version。

整个看起来是那么的表意，使用过Maven更会以为是无缝转换，甚至更简洁。

Dependency configurations 依赖分组

在Gradle中，依赖都被会分配到某一个具体的configuration中（这里我不倾向于翻译成配置，我以为布局，或者分组更适合）。Configuration表明着一个或多个构件及构件所需依赖的一个分组。

Java插件已经预约义了一些configuration，好比，compile，runtime，testCompile，testRuntime等。

compile 放在这个configuration下的依赖是在编译产品代码时所使用的，但它做为一个分组，包含产品代码和编译所需的依赖。 
runtime 产品代码在运行时须要的依赖，默认，也会包含compile中的依赖。 
testCompile 编译测试代码时所须要的依赖，默认，被编译的产品代码和产品代码须要的编译依赖也属于该分组。 
testRuntime 运行测试时须要的依赖。默认，包含compile，runtime和testCompile的分组的构建和依赖。

使用过Maven的都应该知道分组的含义，这里讲解给不明白的同窗，依赖之因此要分组，是由于，每一个阶段对依赖的须要不同，最明显的是产品代码和测试代码，好比junit在产品代码中就不须要。

那么，为何产品代码的编译阶段和运行阶段也分组，通常编译阶段须要的依赖，在运行阶段也须要，可是反过来就不必定了。好比，你经过反射去load一个class，这时该class就不必定须要在编译阶段存在。

一个更常见的例子，作web开发时须要servlet的依赖，可是只是编译阶段，运行时servlet依赖由servlet容器来提供。因此Gradle的War插件也提供了两个configuration，分别是providedCompile和providedRuntime，它们对依赖的使用范围定义和compile以及runtime一致，只不过依赖的Jar包不会被加到War包里面。

定义SourceSet时，添加的Configuration

上一节，在介绍Java插件的时候，提到了SourceSet概念。针对每个新添加的SourceSet，Java插件都会动态的给它添加两个Configuration，分别是sourceSetCompile和sourceSetRuntime。

好比：新添加一个SourceSet，叫作int，那么对应的Configuration是intCompile和intRuntime。

这一特性也正好印证，Java插件是如何识别自定义SourceSet来进行编译和运行。

依赖的多种定义方式

除了经过远程仓库和依赖坐标来定义依赖，Gradle还提供了另外两种经常使用的依赖定义方式，对本地文件的依赖，对某个项目的依赖。

对文件的依赖

这种状况看起来是否是很奇葩，都有依赖管理了和Maven仓库了还要什么文件依赖。其实否则，使用这种定义方式，最多见场景是项目构建工具的迁移，从Ant到Gradle。不管任何项目，迁移过程都是小步前进，Gradle提供文件依赖的配置，就是为了解决这些特殊性。

1 2 3 4

dependencies { runtime files('libs/a.jar', 'libs/b.jar') runtime fileTree(dir: 'libs', include: '*.jar') }

对另外一个工程的依赖

项目中划分子模块是很日常的事情，前端Controller和数据层Dao分离管理就是一个例子，那么在进行前端Controller模块构建时，就须要将数据层模块做为依赖。定义方式以下：

1 2 3

dependencies { compile project(':shared') }

依赖版本冲突

依赖冲突是因此依赖管理中最头痛的问题，这经常出如今传递依赖中。Gradle对解决传递依赖提供了两种策略，使用最新版本或者直接致使构建失败。默认的策略是使用最新版本。虽然这样的策略可以解决一些问题，可是仍是不够。常见的一种状况是，NoSuchMethond或者ClassNotFound。这时候，你可能须要一些特殊手段，好比排除不想要的传递依赖。

排除传递依赖

排除传递依赖有多种缘由，远程仓库中不存在，运行时不须要，或者版本冲突。排除传递依赖的方式有两种：1.直接在configuration中排除 2.在具体的某个dependency中排除

1 2 3 4 5 6 7 8 9 10

configurations { compile.exclude module: 'commons' all*.exclude group: 'org.gradle.test.excludes', module: 'reports' } dependencies { compile("org.gradle.test.excludes:api:1.0") { exclude module: 'shared' } }

经过命令行查看依赖关系

当出现依赖冲突时，最主要的仍是要分析依赖冲突的缘由，Gradle提供了两个任务来帮助你分析依赖关系

dependencies - Displays all dependencies declared in root project ‘projectReports’. 
dependencyInsight - Displays the insight into a specific dependency in root project ‘projectReports’.

Tips：输出依赖关系图到文件

在命令行中直接使用gradle dependencies能够打印出依赖图，可是在命令行中查看始终不太方便，咱们能够将结果输出到一个文件中，以下：

1	gradle dependencies > dependencies.txt

dependencies.txt保存在项目的根目录

Gradle的官方文档中关于Gradle的依赖管理的内容还有不少，好比，如何访问须要用户名密码受权的Maven仓库等等。等多内容，能够参考官方文档：http://gradle.org/docs/current/userguide/dependency_management.html

下一节，利用前三节学到的知识，编写集成测试任务，并单独划分SourceSet。