gradle使用教程一篇就够

gradle使用教程一篇就够

概述

Gradle是新一代构建工具，从0.x版本一路走来虽然国内可寻的资料多了一些，但都是比较碎片化的知识。官方的Userguide虽然是业内良心之作，但无奈太长，且版本变化较快，又鉴于很多同学一看到英文内心便已认定无法读懂，遂打算利用业余时间攒此本《跟我学gradle》，希望通过此书可以降低学习曲线能让希望使用Gradle的同学更轻易地入门。

简介

Gradle是继Maven之后的新一代构建工具，它采用基于groovy的DSL语言作为脚本，相比传统构建工具通过XML来配置而言，最直观上的感受就是脚本更加的简洁、优雅。如果你之前对Maven有所了解，那么可以很轻易的转换到Gradle，它采用了同Maven一致的目录结构，可以与Maven一样使用Maven中央仓库以及各类仓库的资源，并且Gradle默认也内置了脚本转换命令可以方便的将POM转换为。

Gradle的优势

依赖管理:即将你项目中的jar包管理起来，你可以使用Maven或者Ivy的远程仓库、或者本地文件系统等 编译打包:可以通过脚本实现花样打包，包括修改文件、添加抑或排除一些类或资源、采用指定JDK版本构建、打包后自动上传等等等等 多项目支持: Gradle对多项目有着良好的支持，比如一个很具有代表性的实践就是spring framework 多语言支持：无论是java、groovy、scala、c++都有良好的支持 跨平台支持：gradle是基于jvm的，只要有jvm你就可以让gradle运行 灵活的的脚本：你可以使用groovy灵活的编写任务完成你想要做的任何事情

约定优于配置

约定优于配置(convention over configuration),简单而言就是遵循一定的固定规则从而可以避免额外的配置。虽然这一定程度上降低了灵活性，但却能减少重复的额外配置，同时也可以帮助开发人员遵守一定的规则。当然，约定并不是强制性约束，Gradle提供了各种灵活的途径可以让你更改默认的配置。

标准结构

Gradle遵循COC(convention over configuration约定优于配置)的理念,默认情况下提供了与maven相同的项目结构配置 大体结构如下

project root src/main/java(测试) src/main/resources src/test/java(测试源码目录) src/test/resources(测试资源目录) src/main/webapp(web工程)

非标准结构配置

在一些老项目上,可能目录结构并不是标准结构,然而一般开发人员又不好进行结构调整.此时可以通过配置sourceSet来指定目录结构

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

或者采用如下写法也是可以的

sourceSets { s = ['src/java'] s = ['src/resources'] }

在android中

android { sourceSets { main { e ''

s = ['src'] s = ['src'] s = ['src']

s = ['src'] s = ['res'] s = ['assets'] } t('tests') } }

当然如果你的资源目录与源码目录相同这样就比较....了,但你仍然可以按照如下方式搭配include和exclude进行指定

sourceSets { main { java { //your java source paths and exclusions

} resources { srcDir 'main/resources' include '**/*.properties' include '**/*.png' srcDir 'src' include '**/Messages*.properties' exclude '**/*.java'

} } }

一个简单的Gralde脚本,或许包含如下内容,其中标明可选的都是可以删掉的部分

•

•

•

•

•

•

插件引入:声明你所需的插件

属性定义(可选):定义扩展属性

局部变量(可选):定义局部变量

属性修改(可选):指定project自带属性

依赖声明:声明项目中需要哪些依赖

自定义任务(可选):自定义一些任务

buildscript 配置该 Project 的构建脚本的 classpath，在 Andorid Studio 中的 root project 中可以看到 apply(options: Map)我们通过该方法使用插件或者是其他脚本，options里主要选项有：

from： 使用其他脚本，值可以为 (Object) 支持的路径 plugin：使用其他插件，值可以为插件id或者是插件的具体实现类

扩展: Gradle脚本是基于groovy的DSL，这里对上述脚本与Gradle api的关系稍作解释，希望可以帮助你更好的理解groovy与gradle dsl之间的关系

• Project对象 :

什么是依赖管理

通常而言，依赖管理包括两部分，对依赖的管理以及发布物的管理；依赖是指构建项目所需的构件(jar包等)。例如，对于一个应用了spring普通的java web项目而言，spring相关jar包即项目所需的依赖。发布物，则是指项目产出的需要上传的项目产物。

采用变量统一控制版本号

自动获取最新版本依赖

如果你想一些库每次构建时都检查是否有新版本，那么可以采用+来让Gradle在每次构建时都检查并应用最新版本的依赖。当然也可以采用1.x,2.x的方式来获取一些大版本下的最新版本。

依赖的坐标

在gradle中可以通过以下方式来声明依赖:

在gradle中可以通过以下方式来声明依赖:

项目

group

描述

通常用来描述组织、公司、团队或者其它有象征代表意义的名字，比如阿里就是a，一个group下一般会有多个artifact

依赖的名称，或者更直接来讲叫包名、模块、构件名、发布物名以及随便你怎么称呼。druid就是a下的一个连接池库的名称

见名知意，无它，版本号。

类库版本，在前三项相同的情况下，如果目标依赖还存在对应不同JDK版本的版本，可以通过此属性指明

依赖的归档类型，如aar、jar等，默认不指定的话是jar

configurationName

依赖的作用范围，具体介绍看本章第二小节

name

version

classifier

extension

这是由于Gradle依赖配置支持多种书写方式，采用map或者字符串。

显然采用字符串的方式更加简单直观，当然借助groovy语言强大的GString还可以对版本号进行抽离。如下面的示例，这里需要注意的是如果要用GString的话，依赖描述的字符串要用""双引号包起来才会生效。

依赖的范围

tip:这里需要注意的是,provided范围内的传递依赖也不会被打包

名称

compileOnly

说明

gradle2.12之后版本新添加的,2.12版本时期曾短暂的叫provided,后续版本已经改成了compileOnly,由java插件提供,适用于编译期需要而不需要打包的情况

providedCompile

war插件提供的范围类型:与compile作用类似,但不会被添加到最终的war包中这是由于编译、测试阶段代码需要依赖此类jar包，而运行阶段容器已经提供了相应的支持，所以无需将这些文件打入到war包中了;例如Servlet API就是一个很明显的例子.

api

implementation

3.4以后由java-library提供 当其他模块依赖于此模块时，此模块使用api声明的依赖包是可以被其他模块使用

3.4以后由java-library提供 当其他模块依赖此模块时，此模块使用implementation声明的依赖包只限于模块内部使用，不允许其他模块使用。

编译范围依赖在所有的classpath中可用，同时它们也会被打包。

runtime依赖在运行和测试系统的时候需要，但在编译的时候不需要。比如，你可能在编译的时候只需要JDBC API JAR，而只有在运行的时候才需要JDBC驱动实现。

测试期编译需要的附加依赖

测试运行期需要

-

配置默认依赖范围

compile

providedRuntime

同proiveCompile类似。

runtime

testCompile

testRuntime

archives

default

依赖的分类

类型 描述

外部依赖

项目依赖

文件依赖

内置依赖

子模块依赖

依赖存放于外部仓库中,如jcenter ,mavenCentral等仓库提供的依赖

依赖于其它项目(模块)的依赖

依赖存放在本地文件系统中,基于本地文件系统获取依赖

跟随Gradle发行包或者基于Gradle API的一些依赖,通常在插件开发时使用

还没搞清楚是什么鬼

外部依赖

可以通过如下方式声明外部依赖，Gradle支持通过map方式或者g:a:v的简写方式传入依赖描述，这些声明依赖会去配置的repository查找。

项目依赖

此类依赖多见于多模块项目，书写方式如下，其中:是基于跟项目的相对路径描述符。

文件依赖

依赖存在于本地文件系统中，举个栗子，如oracle的OJDBC驱动，中央仓库中没有又没有自建私服此时需要放到项目lib下进行手工加载那么便可采用此种方式，可以通过接口及其子接口提供的方法加载这些依赖(支持文件通配符)

内置依赖

跟随Gradle发行包或者基于Gradle API的一些依赖，通常在插件开发时使用，当前提供了如下三种

子模块依赖

简单来说就是声明依赖的依赖或者依赖的传递依赖，一般情况下如果依赖的库并未用构建工具构建（尤其是一些上古时代的老库），那么Gradle是无法透过源文件去查找该库的传递性依赖的，通常而言，一个模块采用XML(POM文 件)来描述库的元数据和它的传递性依赖。Gradle可以借由此方式提供相同的能力，当然这种方式也会可以改写原有的传递性依赖。这里让druid连接池依赖了的一个库。

什么是传递依赖

在Maven仓库中，构件通过POM（一种XML文件）来描述相关信息以及传递性依赖。Gradle 可以通过分析 该文件获取获取所以依赖以及依赖的依赖和依赖的依赖的依赖，为了更加直观的表述，可以通过下面的输出 结果了解。

image

当然,你也可以全局性的关闭依赖的传递特性。

{ transitive = false }

排除依赖

可以通过configuration配置或者在依赖声明时添加exclude的方式来排除指定的引用。

exclude可以接收group和module两个参数，这两个参数可以单独使用也可以搭配使用，具体理解如下:

强制使用版本

当然，有时候你可能仅仅是需要强制使用一些统一的依赖版本，而不是排除他们，那么此时force就该登场了。指定force = true属性可以冲突时优先使用该版本进行解决。

全局配置强制使用一些版本的依赖来解决依赖冲突中出现的依赖

另一个例子

使用动态版本

如果你想让你的工程始终采用最新依赖，那么Gradle提供了一种方式可以始终保证采用依赖的最新版本而无需每次手工检查修改版本。

• 虽然这是看上去十分风骚的一种用法，但这无疑会降低你系统构建的速度同时提高构建失败的风险。因为Gradle不得不每次检查远程仓库是否存在最新版本，同时新版本也可能带来无法预知的兼容性问题。

一个综合案例

使用文件统一管理项目依赖

1. 在项目的根目录下创建文件

•

•

image

在app的中，我们通常需要配置两个部分

Android 目录下的项目的版本/包名/编译版本等信息

dependencies 目录下的安卓Support库和我们自己引用的第三方库 所以通常我们在文件也将依赖分成两个部分 android/dependencies

3. 在 项目的 文件中引用文件

// 在项目文件的最外层添加引用 apply from: ""

4. 修改app的文件中的项目引用

更新依赖

当远程仓库上传了相同版本依赖时，有时需要为缓存指定一个时效去检查远程仓库的依赖笨版本，Gradle提供了cacheChangingModulesFor(int,

it) ,cacheDynamicVersionsFor(int,

it)两个方法来设置缓存的时效

缓存管理

缓存位置管理

•

•

•

通过添加系统变量 GRADLE_USER_HOME

设置虚拟机参数 属性

通过命令行-g或者 --gradle-user-home 参数设置

离线模式（总是采用缓存内容）

Gradle提供了一种离线模式，可以让你构建时总是采用缓存的内容而无需去联网检查，如果你并未采用动态版本特性且可以确保项目中依赖的版本都已经缓存到了本地，这无疑是提高构建速度的一个好选择。开启离线模式只需要在执行命令时候添加--offline参数即可。当然，采用这种模式的也是有代价的，如果缓存中搜寻不到所需依赖会导致构建失败。

依赖-构件的上传与发布

任务名称 描述

dependencyReport

将项目依赖情况输出到txt文件中 功能同gradle

dependencies > build/dependenciestxt

生成项目属性报告

生成项目任务报告

生成项目报告,包括前四个

htmlDependencyReport

生成HTML版本的依赖情况

propertyReport

taskReport

projectReport