search

Gradle高级使用

Author Avatar
第五季 2016.5.30
字数：3,731字 时长：14分钟
  • 微信扫一扫分享

Gradle简介

　　Gradle傲居构建江湖盟主一位已有好几载，Google Android Studio的推出又将之引入到Android的世界，让我们有幸认识到他的强大。博主在使用之后对他的称赞也是不绝于口，那现在就让我带领你认识这个被称为“神器”的构建工具吧。

Gradle是什么

　　Gradle跟ant/maven一样，是一种依赖管理/自动化构建工具。但是跟ant/maven不一样，它并没有使用xml语言，而是采用了Groovy语言，这使得它更加简洁、灵活，更加强大的是，gradle完全兼容maven和ivy。官方称它是 java ( JVM ) 世界中构建技术的一个飞跃。

Gradle的特点

  1. 声明式构建和合约构建
    Gradle 的核心是基于 Groovy 的 领域特定语言 (DSL), 具有十分优秀的扩展性. Gradle 通过提供可以随意集成的声明式语言元素将声明性构建推到了一个新的高度. 这些元素也为 Java, Groovy, OSGi, Web 和Scala 等项目提供基于合约构建的支持. 而且, 这种声明式语言是可扩展的. 你可以添加自己的语言元素或加强现有的语言元素, 从而提供简洁, 易于维护和易于理解的构建.

  2. 基于依赖的编程语言
    声明式语言位于通用任务图 ( general purpose task graph ) 的顶端，它可以被充分利用在你的构建中. 它具有强大的灵活性, 可以满足使用者对 Gradle 的一些特别的需求.

  3. 让构建结构化
    Gradle 的易适应性和丰富性可让你在构建里直接套用通用的设计原则. 例如, 你可以非常容易地使用一些可重用的组件来构成你的构建. 但是不必要的间接内联内容是不合适的. 不要强行拆分已经结合在一起的部分 (例如, 在你的项目层次结构中). 避免使构建难以维护. 总之, 你可以创建一个结构良好，易于维护和易于理解的构建.

  4. API深化
    你会非常乐意在整个构建执行的生命周期中使用 Gradle, 因为Gradle 允许你管理和定制它的配置和执行行为.

  5. Gradle 扩展
    Gradle 扩展得非常好. 不管是简单的独立项目还是大型的多项目构建, 它都能显著的提高效率. 这是真正的结构构建. 顶尖水平的构建功能，还可以解决许多大公司碰到的构建 性能低下的问题.

  6. 多项目构建
    Gradle 对多项目的支持是非常出色的. 项目依赖是很重要的部分. 它允许你模拟在多项目构建中项目的关系，这正是你所要关注的地方.Gradle 提供了局部构建的功能. 如果你构建一个单独的子项目, Gradle 会构建这个子项目依赖的所有子项目. 你也可以选择依赖于另一个特别的子项目重新构建这些子项目. 这样在一些大型项目里就可以节省非常多的时间.

  7. 多种方式来管理你的依赖
    不同的团队有不同的管理外部依赖的方法. Gradle 对于任何管理策略都提供了合适的支持. 从远程 Maven 和 Ivy 库的依赖管理到本地文件系统的 jars 或者 dirs.

  8. Gradle 是第一个构建整合工具
    Ant 的 tasks是 Gradle 中很重要的部分, 更有趣是 Ant 的 projects 也是十分重要的部分. Gradle 可以直接引入Ant 项目, 并在运行时直接将 Ant targets 转换成 Gradle tasks. 你可以从 Gradle 中依赖它们, 并增强它们的功能, 甚至可以在 build.xml 文件中声明 Gradle tasks 的依赖. 并且properties, paths 等也可以通过同样的方法集成进来.Gradle 完全支持你已有的 Maven 或者 lvy 仓库来构造发布或者提取依赖. Gradle 也提供了一个转化器, 用来将 maven 的 pom.xml 文件转换成 Gradle 脚本. 在运行时引入 Maven 项目也会在稍后推出.

  9. 易于迁移
    Gradle 可以兼容任何结构. 因此你可以直接在你的产品构建的分支上开发你的 Gradle 构建, 并且二者可以并行. 通常建议编写一些测试代码来确保它们的功能是相同的. 通过这种方式, 在迁移的时候就不会显得那么混乱和不可靠, 这是通过婴儿学步的方式来获得最佳的实践.

  10. 基于Groovy
    Gradle 的构建脚本是通过 Groovy 编写的而不是 XML. 但是并不像其他方式, 这并不是为了简单的展示用动态语言编写的原始脚本有多么强大. 不然的话, 只会导致维护构建变得非常困难. Gradle 的整个设计是朝着一种语言的方向开发的, 并不是一种死板的框架. Groovy 就像胶水一样, 把你像实现的构想和抽象的 Gradle 粘在一起. Gradle提供了一些标准的构想, 但是他们并不享有任何形式的特权. 相比于其他声明式构建系统，这是一个比较突出的特点.

  11. Gradle 包装器
    Gradle 包装器允许你在没有安装 Gradle 的机器上运行 Gradle 构建. 在一些持续集成的服务器上, 这个功能将非常有用. 它同样也能降低使用一个开源项目的门槛, 也就是说构建它将会非常简单. 这个包装器对于公司来说也是很有吸引力的. 它并不需要为客户机提供相应的管理防范. 这种方式同样也能强制某一个版本 Gradle 的使用从而最小化某些支持问题.

  12. 免费和开源
    Gradle 是一个开源项目, 遵循 ASL 许可.

Gradle与Maven的区别

　　Java世界中主要有三大构建工具：Ant、Maven和Gradle。经过几年的发展，Ant几乎销声匿迹、Maven也日薄西山，而Gradle的发展则如日中天。

依赖管理系统

　　Maven为Java世界引入了一个新的依赖管理系统。
　　1. 在Java世界中，可以用groupId、artifactId、version组成的Coordination（坐标）唯一标识一个依赖。任何基于Maven构建的项目自身也必须定义这三项属性，生成的包可以是Jar包，也可以是war包或者ear包。一个典型的依赖引用如下所示：

1
2
3
4
5
6
7
8
9
10
<dependency>
 <groupId>junit</groupId>
 <artifactId>junit</artifactId>
 <version>4.12</version>
 <scope>test</scope>
</dependency>
<dependency>
 <groupId>org.springframework</groupId>
 <artifactId>spring-test</artifactId>
</dependency>

　　从上面可以看出当引用一个依赖时，version可以省略掉，这样在获取依赖时会选择最新的版本。而存储这些组件的仓库有远程仓库和本地仓库之分。远程仓库可以使用世界公用的central仓库，也可以使用Apache Nexus自建私有仓库；本地仓库则在本地计算机上。通过Maven安装目录下的settings.xml文件可以配置本地仓库的路径，以及采用的远程仓库的地址。
　　Gradle在设计的时候基本沿用了Maven的这套依赖管理体系。不过它在引用依赖时还是进行了一些改进。首先引用依赖方面变得非常简洁。

1
2
3
4
dependencies {
 compile 'org.hibernate:hibernate-core:3.6.7.Final'
 testCompile ‘junit:junit:4.+'
}

　　2. Maven和Gradle对依赖项的scope有所不同。在Maven世界中，一个依赖项有6种scope，分别是complie(默认)、provided、runtime、test、system、import。而grade将其简化为了4种，compile、runtime、testCompile、testRuntime。那么如果想在gradle使用类似于provided的scope怎么办？别着急，由于gradle语言的强大表现力，我们可以轻松编写代码来实现类似于provided scope的概念（例如How to use provided scope for jar file in Gradle build?）。
　　3. Gradle支持动态的版本依赖。在版本号后面使用+号的方式可以实现动态的版本管理。如下所示：

1
2
3
dependencies {
 compile ‘junit:junit:4.+'
}

　　4. 在解决依赖冲突方面Gradle的实现机制更加明确。使用Maven和Gradle进行依赖管理时都采用的是传递性依赖；而如果多个依赖项指向同一个依赖项的不同版本时就会引起依赖冲突。而Maven处理这种依赖关系往往是噩梦一般的存在。而Gradle在解决依赖冲突方面相对来说比较明确.

多模块构建

　　在SOA和微服务的浪潮下，将一个项目分解为多个模块已经是很通用的一种方式。在Maven中需要定义个parent POM作为一组module的聚合POM。在该POM中可以使用标签来定义一组子模块。parent POM不会有什么实际构建产出。而parent POM中的build配置以及依赖配置都会自动继承给子module。
　　而Gradle也支持多模块构建。而在parent的build.gradle中可以使用allprojects和subprojects代码块来分别定义里面的配置是应用于所有项目还是子项目。对于子模块的定义是放置在setttings.gradle文件中的。在gradle的设计当中，每个模块都是Project的对象实例。而在parent build.gradle中通过allprojects或subprojects可以对这些对象进行各种操作。这无疑比Maven要灵活的多。
比如在parent的build.gradle中有以下代码：

1
2
3
allprojects {
 task hello << { task -> println "I'm $task.project.name" }
}

　　执行命令gradle -q hello会依次打印出父module以及各个submodule的项目名称。这种强大的能力能让gradle对各个模块具有更强的定制化。

一致的项目结构

　　在Ant时代大家创建Java项目目录时比较随意，然后通过Ant配置指定哪些属于source，那些属于testSource等。而Maven在设计之初的理念就是Conversion over configuration（约定大于配置）。其制定了一套项目目录结构作为标准的Java项目结构。一个典型的Maven项目结构如下：
mulu
　　Gradle也沿用了这一标准的目录结构。如果你在Gradle项目中使用了标准的Maven项目结构的话，那么在Gradle中也无需进行多余的配置,只需在文件中包含apply plugin:’java’,系统会自动识别source、resource、test srouce、 test resource等相应资源。不过Gradle作为JVM上的构建工具，也同时支持groovy、scala等源代码的构建，甚至支持Java、groovy、scala语言的混合构建。虽然Maven通过一些插件（比如maven-scala-plugin）也能达到相同目的，但配置方面显然Gradle要更优雅一些。

一致的构建模型

　　为了解决Ant中对项目构建活动缺乏标准化的问题，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
<phases>
 <phase>validate</phase>
 <phase>initialize</phase>
 <phase>generate-sources</phase>
 <phase>process-sources</phase>
 <phase>generate-resources</phase>
 <phase>process-resources</phase>
 <phase>compile</phase>
 <phase>process-classes</phase>
 <phase>generate-test-sources</phase>
 <phase>process-test-sources</phase>
 <phase>generate-test-resources</phase>
 <phase>process-test-resources</phase>
 <phase>test-compile</phase>
 <phase>process-test-classes</phase>
 <phase>test</phase>
 <phase>prepare-package</phase>
 <phase>package</phase>
 <phase>pre-integration-test</phase>
 <phase>integration-test</phase>
 <phase>post-integration-test</phase>
 <phase>verify</phase>
 <phase>install</phase>
 <phase>deploy</phase>
</phases>

　　而这种构建周期也是Maven最为人诟病的地方。因为Maven将项目的构建周期限制的太死，你无法在构建周期中添加新的phase，只能将插件绑定到已有的phase上。而现在项目的构建过程变得越来越复杂，而且多样化，显然Maven对这种复杂度缺少足够的应变能力。比如你想在项目构建过程中进行一项压缩所有javascript的任务，那么就要绑定到Maven的现有的某个phase上，而显然貌似放在哪个phase都不太合适。而且这些phase都是串行的，整个执行下来是一条线，这也限制了Maven的构建效率。而Gradle在构建模型上则非常灵活。在Gradle世界里可以轻松创建一个task，并随时通过depends语法建立与已有task的依赖关系。甚至对于Java项目的构建来说，Gradle是通过名为java的插件来包含了一个对Java项目的构建周期，这等于Gradle本身直接与项目构建周期是解耦的。

插件机制

　　Maven和Gradle设计时都采用了插件机制。但显然Gradle更胜一筹。主要原因在于Maven是基于XML进行配置。所以其配置语法太受限于XML。即使实现很小的功能都需要设计一个插件，建立其与XML配置的关联。比如想在Maven中执行一条shell命令，其配置如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
<plugin>
 <groupId>org.codehaus.mojo</groupId>
 <artifactId>exec-maven-plugin</artifactId>
 <version>1.2</version>
 <executions>
 <execution>
 <id>drop DB => db_name</id>
 <phase>pre-integration-test</phase>
 <goals>
 <goal>exec</goal>
 </goals>
 <configuration>
 <executable>curl</executable>
 <arguments>
 <argument>-s</argument>
 <argument>-S</argument>
 <argument>-X</argument>
 <argument>DELETE</argument>
 <argument>http://${db.server}:${db.port}/db_name</argument>
 </arguments>
 </configuration>
 </execution>
 </executions>
</plugin>

　　而在Gradle中则一切变得非常简单。

1
2
3
task dropDB(type: Exec) {
 commandLine ‘curl’,’-s’,’s’,’-x’,’DELETE’,"http://${db.server}:{db.port}/db_name"
}

为什使用Gradle

　　在脚本构建时, 一个内部的 DSL（基于一个动态语言）相对于 XML 的优势是巨大的. 有这么多的动态语言, 为什么选择 Groovy? 答案在于 Gradle 的运行环境. 虽然 Gradle 以一个通用构建工具为核心, 但是它的重点是Java项目. 在这样的项目中, 显然团队每个成员都对 Java 非常熟悉. 而且构建应尽可能对所有团队成员都是透明的,所以选择了 Groovy.
　　那么，为什么不直接使用 Java 作为构建脚本的语言. 这是一个很好的问题. 对于你的团队, 它要有最高的透明度和最低的学习曲线, 也就是说容易掌握. 但由于 Java 的限制, 这样的构建语言不会那么完美和强大. 而像 Python，Groovy 或 Ruby 语言用来作为构建语言会更好. 之所以使用 Groovy 是因为它给 Java 开发人员提供了迄今为止最大的透明度. 其基本的符号和类型与 Java 是一样的，其封装结构和许多其他的地方也是如此. Groovy 在这基础上提供了更多的功能, 而且与 java 有共同的基础。

Powered by Hexo
Theme - Material