您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  要资料 文章 文库 Lib 视频 Code iProcess 课程 认证 咨询 工具 讲座吧   成长之路  
会员   
 
   
 
  
每天15篇文章
不仅获得谋生技能
更可以追随信仰
 
 
     
   
 订阅
  捐助
灵活强大的构建系统Gradle
 
来源:聚客 发布于 2016-3-1
来自于要资料   934 次浏览     评价:      
 

前言

构建,软件生命周期中重要的一环,在现代软件开发过程中,起着越来越重要的作用。过去在Java或类Java的世界里,Ant、Maven再熟悉不过了,Maven凭借其强大的依赖配置战胜Ant,基本上成为了Java构建的标准。而在现代,系统日益复杂,构建的灵活性要求越来越高,比如:构建过程中需要打包上传到服务器,Maven无法很好地支持这种复杂的系统构建,所以,我选择了Gradle,一个基于Groovy,更灵活更强大的构建系统,能帮助我们构建更复杂的项目。

为什么选择Gradle

从框架方向来看:

Gradle是很成熟的技术,可以处理大规模构建

Gradle对多语言、多平台有更natural的支持

Gradle关注在构建效率上

Gradle发布很频繁,重要feature开发计划透明化

Gradle社区很活跃,并且增加迅速

从语言特性来看:

1.代码很精简

2.Gradle基于Groovy,能完成复杂系统的构建任务

3.DSL比XML更简洁高效

Gradle在开源项目中的使用

现在使用Gradle构建的开源项目很多,我有过接触的比如:Grails, Griffon, Groovy, Hibernate, Spring

还有很多其它开源项目也都在用Gradle,比如Tapestry,Qi4J,Netflix下所有开源项目(python、c++、html等除外)等等。

Gradle在企业中的使用

现在使用Gradle来做构建体系的公司也越来越多,linkedin就很早开始切换到Gradle。

Gradle体验

Gradle的安装非常方便,下载ZIP包,解压到本地目录,设置 GRADLE_HOME 环境变量并将 GRADLE_HOME/bin 加到 PATH 环境变量中,安装就完成了。用户可以运行gradle -v命令验证安装,这些初始的步骤和Maven没什么两样。我这里安装的Gradle版本是1.10,详细信息见下:

bob [10:42]  ? gradle -v

------------------------------------------------------------
Gradle 1.10
------------------------------------------------------------
Build time: 2013-12-17 09:28:15 UTC
Build number: none
Revision: 36ced393628875ff15575fa03d16c1349ffe8bb6
Groovy: 1.8.6
Ant: Apache Ant(TM) version 1.9.2 compiled on July 8 2013
Ivy: 2.2.0
JVM: 1.7.0_45 (Oracle Corporation 24.45-b08)
OS: Mac OS X 10.9.2 x86_64

Gradle的Features很多,官网doc介绍很详细,我这里就不多说。下面简单介绍一下Gradle构建相关的东西。

Gradle基础

1,Gradle有两个最基本的概念:project和task。Gradle里面的所有东西都基于这两个概念。project通常指一个项目,而task指构建过程中的任务。一次构建可以有1到n个project,每个project有1到n个task。

2,Gradle有一个类似Maven中pom.xml的配置文件:build.gradle。功能也基本一样,负责当前project的构建定义。看一个build.gradle的简单例子:

bob [10:46]  ? pwd
/Users/bob/framework/gradle-1.10/samples/userguide/tutorial/hello
// 在你安装的gradle根目录下有对应的samples目录,里面有很多例子

bob [10:46] ? cat build.gradle
task hello {
doLast {
println 'Hello world!'
}
}

文件中定义了一个task:hello,task的内容是 "println 'Hello world!'",我们来执行一下:

bob [10:49]  ? gradle -q hello
Hello world!

可以看到,输出了"Hello world!",这里-q的意思是quiet模式,只输出构建中的必要信息。

gradle里可以定义多个task,task之间也可以有依赖关系,还可以定义默认task,看一个例子:

带有task依赖关系:

bob [10:53]  ? cat userguide/tutorial/lazyDependsOn/build.gradle
task taskX(dependsOn: 'taskY') << {
println 'taskX'
}
task taskY << {
println 'taskY'
}

带有默认task例子:

bob [10:59]  ? cat userguide/tutorial/defaultTasks/build.gradle
defaultTasks 'clean', 'run'


task clean << {
println 'Default Cleaning!'
}

task run << {
println 'Default Running!'
}

task other << {
println "I'm not a default task!"
}

看看执行情况:

bob [10:59]  ? gradle -q
Default Cleaning!
Default Running!

bob [11:00] ? gradle -q other
I'm not a default task!

默认task,当没有task指定时,则会执行默认的task。

Gradle依赖

Gradle和Maven在依赖管理上几乎差不多,核心的概念是一样的,只不过Gradle语法更精简,并且多了一些更灵活的自定义配置。我们先看一个例子,Maven的pom.xml:

<dependencies>
<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:3.2.4.RELEASE')
compile('org.springframework:spring-beans:3.2.4.RELEASE')
compile('org.springframework:spring-context:3.2.4.RELEASE')
testCompile('junit:junit:4.7')
}

代码块少了很多。试想,生产环境下的中、大型应用如果用都用Gradle替换Maven,那势必会大大减少配置文件代码块,并有更强的可读性,也就意味着系统更加稳健。

1,Gradle在依赖配置上面,和Maven一样,支持传递性依赖,然后和Maven不同的是,它还支持排除传递性依赖以及关闭传递性依赖。

2,Gradle的依赖scope,也基本和Maven一样,不过它是通过配置来定义,plugin来支撑和加强的,所以除了基本的compile、runtime等scope外,Gradle还可以自定义出很多配置,针对不同的配置写不同的task来完成更复杂更灵活的构建任务。

依赖相关的仓库配置很灵活,支持多种repository,看下面repository定义例子:

bob [11:07]  ? cat userguide/artifacts/defineRepository/build.gradle

repositories {
mavenCentral() // 定义仓库为maven中心仓库
}
repositories {
jcenter() // 定义仓库为jcenter仓库
}
repositories {
maven {
url "http://repo.mycompany.com/maven2" // 定义依赖包协议是maven,地址是公司的仓库地址
}
}
repositories { // 定义本地仓库目录
flatDir {
dirs 'lib'
}
}
repositories { // 定义ivy协议类型的仓库
ivy {
url "http://repo.mycompany.com/repo"
}
}

可以看到,对于常用的maven、ivy、local以及jcenter的repository都有支持,语法很简单。而且还可以通过编写task来支持更复杂的repository,更多详情可以查看安装包里的对应目录下文件查看。

Gradle构建

和Maven一样,Gradle也是通过artifact来打包构建的。得益于上述的Gradle本身的特性,artifact在Gradle里实现得更灵活一些。看一个例子:

bob [13:00]  ? cat userguide/artifacts/uploading/build.gradle

## jar类型的artifact
task myJar(type: Jar)
artifacts {
archives myJar
}
## file类型的artifact
def someFile = file('build/somefile.txt')
artifacts {
archives someFile
}

## 根据自定义task来完成artifact
task myTask(type: MyTaskType) {
destFile = file('build/somefile.txt')
}
artifacts {
archives(myTask.destFile) {
name 'my-artifact'
type 'text'
builtBy myTask
}
}

## 根据自定义task来完成artifact
task generate(type: MyTaskType) {
destFile = file('build/somefile.txt')
}
artifacts {
archives file: generate.destFile, name: 'my-artifact', type: 'text', builtBy: generate
}

这样就简单地定义了好几种artifact生成的定义,根据不同的场景需求,生成文本文件、jar包或者zip,还可以再上传到服务器上。
一般情况下,常用的插件,比如说"Java plugin"都默认定义了"jar"这样的artifact task,所以一般不需要额外开发。但是,针对于一些复杂情况,或者在plugin基础上增强的话,自定义artifact task还是非常有用的。

Gradle构建的项目,发布到仓库中,也非常容易:

apply plugin: 'maven'

uploadArchives {
repositories {
ivy {
credentials {
username "username"
password "pw"
}
url "http://repo.mycompany.com"
}
}
}

Gradle 插件

上面简介介绍了一下Gradle的一些概念和配置,要用到项目中run起来,现在还还要一步,就是本节介绍的Gradle插件。Gradle现在已经支持很多插件,这给开发者带来极大的便利,先说说Java插件吧。

1,使用Java plugin,只需要在build.gradle中加入这句话:

apply plugin: 'java'

2,了解或设置Java project布局。Gradle和Maven一样,采用了“约定优于配置”的方式对Java project布局,并且布局方式是和Maven一样的,此外,Gradle还可以方便的自定义布局。在Gradle中,一般把这些目录叫做source set。看下官方的答案:

这里要注意,每个plugin的source set可能都不一样。

同样的,Java plugin还定义好了一堆task,让我们可以直接使用,比如:clean、test、build等等。这些task都是围绕着Java plugin的构建生命周期的:

图中每一块都是一个task,箭头表示task执行顺序/依赖,比如执行task jar,那么必须先执行task compileJava和task processResources。另外可以看到,Gradle的Java plugin构建生命周期比较复杂,但是也表明了更加灵活,而且,在项目中,一般只使用其中常用的几个:clean test check build 等等。

gradle构建过程中,所有的依赖都表现为配置,比如说系统运行时的依赖是runtime,gradle里有一个依赖配置叫runtime,那么系统运行时会加载这个依赖配置以及它的相关依赖。这里说的有点绕,可以简单理解依赖和maven类似,只不过gradle用configuration实现,所以更灵活,有更多选择。下图是依赖配置关系图以及和task调用的关系图:

可以看到,基本和Maven是一样的。其实Gradle里面这些依赖(scope)都是通过configuration来实现的,这里就不细说,有兴趣的可以研究一下官方资料。

关于“约定优于配置”,还有很多东西,这里不细说,官方doc已经说的很详细了。

Gradle 其它不错的特性

1,所有声明都是一等公民

2,多project构建

3,引用外部/通用构建脚本

4,Gradle wrapper

小结

1,Gradle非常简洁,项目本身的配置代码非常少。

2,Gradle在外部project构建也支持很好,整体构建简单,并且通过公用外部构建脚本,让配置内容尽量没有冗余。

3,Gradle很灵活,可以方面的增加和修改构建过程。而Maven却需要开发插件来支持。

4,Gradle是基于Groovy的,也就是说配置中可以编写自定义代码,能适应更复杂的场景,能完成更强大的功能,比如说:自动上传、分发、部署等等。

项目实战

Gradle介绍了那么多,可以看出,gradle是非常灵活的,可以适应各种复杂环境。建议各位从架构角度考虑gradle构建,而不仅仅把它当作一个构建工具。下面来说说我们实际项目中的Gradle改造工作。

背景:

我们的项目经过一个半Q的迅速发展,整个项目已经由1个简易后台变成4个系统+若干脚本任务了,项目中存在很多冗余代码和重复配置。我们使用上面介绍的方法对项目进行了改造,以解决这两个问题。

步骤:

要解决冗余代码和通用配置的问题,最简单的做法就是抽取出共同部分,作为其它所有项目的parent/common项目。方法:

1,使用git submodule

将所有系统中公共的类库和通用的配置,放到独立的仓库Common中。因为我们用git来管理代码,而git本身提倡多branch,多仓库,所以采用git submodule方式,其它项目需要添加Common这个submodule:

git submodule add yourGitRepo deps/Common

最后的"deps/Common"是自定义的,意思就是在当前的deps目录下用Common名字来当作submodule的clone。

如果你clone别的带有submodule的项目时,默认情况下,当前的project并不会把submodule的代码都clone下来,可以执行:

git submodule foreach git pull

以下这段一般大家经常会遇到:

当你clone项目时,submodule会以最新的master分支上的commit id作为本次的tag下载,类似一个副本,因为一般大家都是用submodule,而不是修改它。所以当你的submodule需要更新的时候,需要先执行这段代码:

git submodule foreach git checkout master

让submodule切换到master分支了,然后就可以用上面的submodule pull来更新了。

2,gradle构建:

鉴于上文对gradle优点的描述,我们采用gradle来构建。我们的项目最初都是基于maven来构建的,从maven切换到gradle很简单,在项目根目录下,先执行(假设你的机器已经安装了gradle环境,一般负责构建的人首次需要安装,开发人员可以不安装):

gradle init wrapper

这样,就会自动生成相关的gradlew,build.gradle,settings.gradle等文件和相关目录,并会自动下载对应版本的gradle binary包(所以以后不需要安装)。Gradle会自动识别Maven里的配置,并相应的导入进来,有少量部分配置可能需要修改。

注:在已有的gradle项目里,尽量使用生成的gradlew这个wrapper,因为它会自动下载对应版本的Gradle,也就是说团队合作的其他人开发机上是不需要手动安装Gradle的,并且wrapper也让大家的Gradle版本一致,避免问题。

3,gradle脚本修改

上面执行完之后,环境已经准备好了,现在要做的就是修改构建脚本:

因为已经通过git submodule把公共项目放到独立目录(deps/Common)了,并且它本身也是独立可构建的项目,那么也就是说当前有两个项目了,一个是当前project,一个是Common项目,要做的就是告诉gradle,要多项目构建,编辑settings.gradle,增加项目配置:

include "deps:Common"

以上就是把Common引入到当前项目了。

根据项目的不同,然后对应修改build.gradle,就大功告成了。看一个例子:

// 这一段主要是把公共库Common的构建脚本引入,因为一般会有通用的配置在里面
def userGradleScript = file("deps/Common/build.gradle")
if (userGradleScript.exists()) {
apply from: userGradleScript
}
// 使用war插件,这样就默认引入了java插件
apply plugin: 'war'
// for jetty
apply plugin: 'jetty'
stopKey = 'yourStopKey' // 自定义的stopkey
stopPort = xxxx // 停止端口
httpPort = xxxx // 启动http端口

// 项目属性
group = 'yourApp'
version = '1.0.0'
description = """这里描述你的项目"""


// checkstyle config文件地址
checkstyle {
configFile = file("deps/Common/config/checkstyle/checkstyle.xml")
}
// lib依赖
dependencies {
// 依赖公共库Common,compile是和maven里的compile scope一样
compile project(':deps:Common')
compile 'commons-validator:commons-validator:1.4.0'
compile('javax.servlet.jsp.jstl:jstl-api:1.2') {
exclude(module: 'servlet-api') // 防止版本冲突
}
compile 'javax.persistence:persistence-api:1.0.2'
runtime 'mysql:mysql-connector-java:5.1.26'
providedCompile 'org.apache.tomcat:tomcat-servlet-api:7.0.30'
// providedCompile 这个conf在java插件里是报错的,war里是正确的
providedCompile 'javax.servlet.jsp:jsp-api:2.1'
...
}

我们再来简单看下公共项目Common的构建脚本:

// 定义一堆基础插件
apply plugin: 'java'
apply plugin: 'maven'
apply plugin: "jacoco"
apply plugin: 'checkstyle'
apply plugin: 'pmd'
apply plugin: 'findbugs'
apply plugin: 'eclipse'
apply plugin: 'idea'
// 定义项目属性
group = 'Common'
version = '1.0.0'
description = """Giant common library"""

// 定义依赖仓库
repositories {
mavenCentral()
}
// project的额外属性,这里用于定义profile属性,模拟maven的profile
ext {
if (project.hasProperty('profile')) {
profile = project['profile']
} else {
profile = "dev"
}
println "profile:" + profile
}
// 额外增加source path
sourceSets {
main {
resources {
srcDir "src/main/profiles/${profile}"
}
}
}
// project依赖
dependencies {
compile 'ch.qos.logback:logback-core:1.0.13'
compile 'ch.qos.logback:logback-classic:1.0.13'
compile 'ch.qos.logback:logback-access:1.0.13'
compile 'commons-io:commons-io:2.0.1'
compile 'commons-lang:commons-lang:2.6'
compile 'joda-time:joda-time:1.6.2'
compile 'org.testng:testng:6.8.7'
compile 'com.googlecode.jmockit:jmockit:1.5'
...
}
// task配置
checkstyle {
ignoreFailures = true
sourceSets = [sourceSets.main]
}
findbugs {
ignoreFailures = true
sourceSets = [sourceSets.main]
}
pmd {
ruleSets = ["basic", "braces", "design"]
ignoreFailures = true
sourceSets = [sourceSets.main]
}
jacocoTestReport {
reports {
xml.enabled true
html.enabled true
csv.enabled false
}
sourceSets sourceSets.main
}
tasks.withType(Compile) {
options.encoding = "UTF-8"
}
test {
useTestNG()
jacoco {
excludes = ["org.*"]
}
}

这样,就可以在公共项目里配置好一堆基础的task,dependencies等等,而使用这个公共项目的其它项目则可以直接使用,无需再额外配置。

4,run

脚本修改完了,就可以开始构建了(不需要安装gradle,直接使用生成的gradlew就行):

./gradlew build

// 基于profile构建
./gradlew -Pprofile=dev build

常用构建命令:

clean:清除之前的构建

test:执行测试

compileJava:编译java

check:在test之后做一个check,一般代码检查插件,都是在这个阶段做的

build:构建打包

总结

随着公司业务的发展,软件系统变得日益复杂和庞大,这就要求有更灵活、更高效的构建系统来支撑。现代构建系统Gradle提供了强大的功能、简洁的语法、灵活的配置,能适应各种复杂的构建环境。利用多project构建,让整个系统模块化,管理更高效。

   
 订阅
  捐助
相关文章

为什么要做持续部署?
剖析“持续交付”:五个核心实践
集成与构建指南
持续集成工具的选择-装载
相关文档

持续集成介绍
使用Hudson持续集成
持续集成之-依赖管理
IPD集成产品开发管理
相关课程

配置管理、日构建与持续集成
软件架构设计方法、案例与实践
单元测试、重构及持续集成
基于Android的单元、性能测试
 

集成与构建指南
项目管理:Maven让事情变得简单
持续集成工具hudson
持续集成
Maven权威指南
程序集(UML中的包)之间循环
更多...   


产品发布管理
配置管理方法、实践、工具
多层次集成配置管理
使用CC与CQ进行项目实践
CVS与配置管理
Subversion管理员

相关咨询服务
SCM启动咨询
SCM流程规范咨询
SCM评估性咨询


海航股份 重构及持续集成
电研华源 设计原理、建模与重构
软件配置管理日构建及持续集成
单元测试、重构及持续集成
中国软件研发中心 单元测试与重构
单元测试、重构和持续集成实践
罗克韦尔 C++单元测试+重构+Gtest
更多...   
 
 
 
 
 
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
 
 

关于我们 | 联系我们 | 京ICP备10020922号 京公海网安备110108001071号