gradle使用教程一篇就够
概述
Gradle是新一代构建工具，从0.x版本一路走来虽然国内可寻的资料多了一些，但都是比较碎片化的知识。官方的Userguide虽然是业内良心之作，但无奈太长，且版本变化较快，又鉴于很多同学一看到英文内心便已认定无法读懂，遂打算利用业余时间攒此本《跟我学gradle》，希望通过此书可以降低学习曲线能让希望使用Gradle的同学更轻易地入门。
简介
Gradle是继Maven之后的新一代构建工具，它采用基于groovy的DSL语言作为脚本，相比传统构建工具通过XML来配置而言，最直观上的感受就是脚本更加的简洁、优雅。如果你之前对Maven有所了解，那么可以很轻易的转换到Gradle，它采用了同Maven一致的目录结构，可以与Maven一样使用Maven中央仓库以及各类仓库的资源，并且Gradle默认也内置了脚本转换命令可以方便的将POM转换为gradle.build。
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 { main.java.srcDirs = ['src/java'] sources.srcDirs = ['src/resources'] }
在android中
android { sourceSets { main { manifest.srcFile 'l' java.srcDirs = ['src'] resources.srcDirs = ['src'] aidl.srcDirs = ['src'] renderscript.srcDirs = ['src'] res.srcDirs = ['res'] assets.srcDirs = ['assets'] } androidTest.setRoot('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<String, ?>)我们通过该方法使用插件或者是其他脚本，options里主要选项有：
from： 使用其他脚本，值可以为 Project.uri(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中可以通过以下方式来声明依赖:
项目 | 描述 |
configurationName | 依赖的作用范围，具体介绍看本章第二小节 |
group | 通常用来描述组织、公司、团队或者其它有象征代表意义的名字，比如阿里就是com.alibaba，一个group下一般会有多个artifact |
name | 依赖的名称，或者更直接来讲叫包名、模块、构件名、发布物名以及随便你怎么称呼。druid就是com.alibaba下的一个连接池库的名称 |
version | 见名知意，无它，版本号。 |
classifier | 类库版本，在前三项相同的情况下，如果目标依赖还存在对应不同JDK版本的版本，可以通过此属性指明 |
extension | 依赖的归档类型，如aar、jar等，默认不指定的话是jar |
这是由于Gradle依赖配置支持多种书写方式，采用map或者字符串。
显然采用字符串的方式更加简单直观，当然借助groovy语言强大的GString还可以对版本号进行抽离。如下面的示例，这里需要注意的是如果要用GString的话，依赖描述的字符串要用""双引号包起来才会生效。
依赖的范围
tip:这里需要注意的是,provided范围内的传递依赖也不会被打包
名称 | 说明 |
compileOnly | gradle2.12之后版本新添加的,2.12版本时期曾短暂的叫provided,后续版本已经改成了compileOnly,由java插件提供,适用于编译期需要而不需要打包的情况 |
providedCompile | war插件提供的范围类型:与compile作用类似,但不会被添加到最终的war包中这是由于编译、测试阶段代码需要依赖此类jar包，而运行阶段容器已经提供了相应的支持，所以无需将这些文件打入到war包中了;例如Servlet API就是一个很明显的例子. |
api | 3.4以后由java-library提供 当其他模块依赖于此模块时，此模块使用api声明的依赖包是可以被其他模块使用 |
implementation | 3.4以后由java-library提供 当其他模块依赖此模块时，此模块使用implementation声明的依赖包只限于模块内部使用，不允许其他模块使用。 |
compile | 编译范围依赖在所有的classpath中可用，同时它们也会被打包。 |
providedRuntime | 同proiveCompile类似。 |
runtime | runtime依赖在运行和测试系统的时候需要，但在编译的时候不需要。比如，你可能在编译的时候只需要JDBC API JAR，而只有在运行的时候才需要JDBC驱动实现。 |
testCompile | 测试期编译需要的附加依赖 |
testRuntime | 测试运行期需要 |
archives | - |
default | 配置默认依赖范围 |
依赖的分类
android最新版类型 | 描述 |
外部依赖 | 依赖存放于外部仓库中,如jcenter ,mavenCentral等仓库提供的依赖 |
项目依赖 | 依赖于其它项目(模块)的依赖 |
文件依赖 | 依赖存放在本地文件系统中,基于本地文件系统获取依赖 |
内置依赖 | 跟随Gradle发行包或者基于Gradle API的一些依赖,通常在插件开发时使用 |
子模块依赖 | 还没搞清楚是什么鬼 |
外部依赖
可以通过如下方式声明外部依赖，Gradle支持通过map方式或者g:a:v的简写方式传入依赖描述，这些声明依赖会去配置的repository查。
项目依赖
此类依赖多见于多模块项目，书写方式如下，其中:是基于跟项目的相对路径描述符。
文件依赖
依赖存在于本地文件系统中，举个栗子，如oracle的OJDBC驱动，中央仓库中没有又没有自建私服此时需要放到项目lib下进行手工加载那么便可采用此种方式，可以通过接口及其子接口提供的方法加载这些依赖(支持文件通配符)
内置依赖
跟随Gradle发行包或者基于Gradle API的一些依赖，通常在插件开发时使用，当前提供了如下三种
子模块依赖
简单来说就是声明依赖的依赖或者依赖的传递依赖，一般情况下如果依赖的库并未用构建工具构建（尤其是一些上古时代的老库），那么Gradle是无法透过源文件去查该库的传递性依赖的，通常而言，一个模块采用XML(POM文 件)来描述库的元数据和它的传递性依
赖。Gradle可以借由此方式提供相同的能力，当然这种方式也会可以改写原有的传递性依赖。这里让druid连接池依赖了ptj.tiger的一个库。
什么是传递依赖
在Maven仓库中，构件通过POM（一种XML文件）来描述相关信息以及传递性依赖。Gradle 可以通过分析 该文件获取获取所以依赖以及依赖的依赖和依赖的依赖的依赖，为了更加直观的表述，可以通过下面的输出 结果了解。
image
当然,你也可以全局性的关闭依赖的传递特性。
configurations.all { transitive = false }
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。
发表评论