Coding ManGradle简介
1. 概述
Gradle 是一个基于 Groovy 的构建管理系统，专为构建基于 Java 的项目而设计。
安装说明可以在这里 找到。
2. 构建模块——项目和任务
在 Gradle 中，构建由一个或多个项目组成，每个项目由一个或多个任务组成。 Gradle 中的项目可以组装一个jar、war甚至一个zip文件。 **任务是一项工作。**这可以包括编译类，或创建和发布 Java/Web 档案。
一个简单的任务可以定义为：
task hello {
doLast {
println 'Blogdemo'
}
}
如果我们使用gradle -q hello命令从build.gradle所在的同一位置执行上述任务，我们应该会在控制台中看到输出。
2.1.任务
Gradle 的构建脚本不过是 Groovy：
task toLower {
doLast {
String someString = 'HELLO FROM BLOGDEMO'
println "Original: "+ someString
println "Lower case: " + someString.toLowerCase()
}
}
我们可以定义依赖于其他任务的任务。任务依赖可以通过在任务定义中传递dependsOn: taskName参数来定义：
task helloGradle {
doLast {
println 'Hello Gradle!'
}
}
task fromBlogdemo(dependsOn: helloGradle) {
doLast {
println "I'm from Blogdemo"
}
}
2.2. 向任务添加行为
我们可以定义一个任务并通过一些额外的行为来增强它：
task helloBlogdemo {
doLast {
println 'I will be executed second'
}
}
helloBlogdemo.doFirst {
println 'I will be executed first'
}
helloBlogdemo.doLast {
println 'I will be executed third'
}
helloBlogdemo {
doLast {
println 'I will be executed fourth'
}
}
doFirst和doLast分别在动作列表的顶部和底部添加动作，并且可以在单个任务中多次定义。
2.3. 添加任务属性
我们还可以定义属性：
task ourTask {
ext.theProperty = "theValue"
}
在这里，我们将*“theValue”设置为ourTask*任务的属性。
3. 管理插件
Gradle 中有两种类型的插件——script和binary。
要从附加功能中受益，每个插件都需要经历两个阶段：resolving 和applying。
**resolving 意味着找到正确版本的插件 jar 并将其添加到项目的classpath 中。
applying 插件是在项目上执行Plugin.apply(T) 。
3.1. 应用脚本插件
在*aplugin.gradle 中，*我们可以定义一个任务：
task fromPlugin {
doLast {
println "I'm from plugin"
}
}
如果我们想将此插件应用到我们的项目build.gradle文件中，我们需要做的就是将这一行添加到我们的build.gradle 中：
apply from: 'aplugin.gradle'
现在，执行gradle tasks命令应该会在任务列表中显示fromPlugin任务。
3.2. 使用插件 DSL 应用二进制插件
在添加核心二进制插件的情况下，我们可以添加短名称或插件 ID：
plugins {
id 'application'
}
现在*application 插件中的run *任务应该可以在项目中使用以执行任何可运行的jar。要应用社区插件，我们必须提到一个完全合格的插件 id：
plugins {
id "org.shipkit.bintray" version "0.9.116"
}
现在，Shipkit任务应该在*gradle *任务列表中可用。
插件 DSL 的限制是：
- 它不支持*plugins *块内的 Groovy 代码
- plugins块需要是项目构建脚本中的顶级语句（在它之前只允许*buildscripts{}*块）
- 插件 DSL 不能写在脚本插件、settings.gradle文件或 init 脚本中
插件 DSL 仍在孵化中。DSL 和其他配置可能会在以后的 Gradle 版本中发生变化。
3.3. 应用插件的旧程序
我们也可以使用*“apply plugin”*来应用插件：
apply plugin: 'war'
如果我们需要添加社区插件，我们必须使用*buildscript{}*块将外部 jar 添加到构建类路径中。
然后，*我们可以在构建脚本中应用插件，但只能在任何现有的*plugins{}块之后：
buildscript {
repositories {
maven {
url "https://plugins.gradle.org/m2/"
}
}
dependencies {
classpath "org.shipkit:shipkit:0.9.117"
}
}
apply plugin: "org.shipkit.bintray-release"
4. 依赖管理
Gradle 支持非常灵活的依赖管理系统，它兼容各种可用的方法。
Gradle 中依赖管理的最佳实践是版本控制、动态版本控制、解决版本冲突和管理传递依赖。
4.1. 依赖配置
依赖项被分组到不同的配置中。配置有一个名称，它们可以相互扩展。
如果我们应用 Java 插件，我们将拥有可用于对依赖项进行分组的compile、testCompile和runtime时配置。default 配置扩展了“runtime”。
4.2. 声明依赖
让我们看一个使用几种不同方式添加一些依赖项（Spring 和 Hibernate）的示例：
dependencies {
compile group:
'org.springframework', name: 'spring-core', version: '4.3.5.RELEASE'
compile 'org.springframework:spring-core:4.3.5.RELEASE',
'org.springframework:spring-aop:4.3.5.RELEASE'
compile(
[group: 'org.springframework', name: 'spring-core', version: '4.3.5.RELEASE'],
[group: 'org.springframework', name: 'spring-aop', version: '4.3.5.RELEASE']
)
testCompile('org.hibernate:hibernate-core:5.2.12.Final') {
transitive = true
}
runtime(group: 'org.hibernate', name: 'hibernate-core', version: '5.2.12.Final') {
transitive = false
}
}
我们在各种配置中声明依赖关系：compile、testCompile和runtime以各种格式。
有时我们需要具有多个工件的依赖项。在这种情况下，我们可以添加一个仅工件符号*@extensionName*（或扩展形式的ext）来下载所需的工件：
runtime "org.codehaus.groovy:groovy-all:[[email protected]](/cdn_cgi/l/email_protection)"
runtime group: 'org.codehaus.groovy', name: 'groovy-all', version: '2.4.11', ext: 'jar'
在这里，我们添加了*@jar*符号以仅下载没有依赖项的 jar 工件。
要将依赖项添加到任何本地文件，我们可以使用以下内容：
compile files('libs/joda-time-2.2.jar', 'libs/junit-4.12.jar')
compile fileTree(dir: 'libs', include: '*.jar')
当我们想避免传递依赖时，我们可以在配置级别或依赖级别上做到这一点：
configurations {
testCompile.exclude module: 'junit'
}
testCompile("org.springframework.batch:spring-batch-test:3.0.7.RELEASE"){
exclude module: 'junit'
}
5. 多项目构建
5.1. 构建生命周期
在初始化阶段，Gradle 确定哪些项目将参与多项目构建。
这通常在位于项目根目录的settings.gradle文件中提到。Gradle 还会创建参与项目的实例。
在配置阶段，所有创建的项目实例都是根据 Gradle 特性配置按需配置的。
在此功能中，仅为特定任务执行配置所需的项目。这样，大大减少了大型多项目构建的配置时间。此功能仍在孵化中。
最后，**在执行阶段，执行创建和配置的任务子集。**我们可以在settings.gradle和build.gradle文件中包含代码来感知这三个阶段。
在settings.gradle：
println 'At initialization phase.'
在build.gradle：
println 'At configuration phase.'
task configured { println 'Also at the configuration phase.' }
task execFirstTest { doLast { println 'During the execution phase.' } }
task execSecondTest {
doFirst { println 'At first during the execution phase.' }
doLast { println 'At last during the execution phase.' }
println 'At configuration phase.'
}
5.2. 创建多项目构建
我们可以在根文件夹中执行gradle init命令来为settings.gradle和build.gradle文件创建一个骨架。
所有常用配置都将保存在根构建脚本中：
allprojects {
repositories {
mavenCentral()
}
}
subprojects {
version = '1.0'
}
设置文件需要包含根项目名称和子项目名称：
rootProject.name = 'multi-project-builds'
include 'greeting-library','greeter'
现在我们需要有几个名为greeting-library和greeter的子项目文件夹来进行多项目构建的演示。每个子项目都需要有一个单独的构建脚本来配置它们各自的依赖项和其他必要的配置。
如果我们想让我们的greeter项目依赖于greeting-library，我们需要在greeter的构建脚本中包含依赖：
dependencies {
compile project(':greeting-library')
}
6. 使用 Gradle Wrapper
如果一个 Gradle 项目有Linux的gradlew文件和 Windows 的gradlew.bat文件，我们不需要安装 Gradle 来构建项目。
如果我们在 Windows 中执行gradlew build并在 Linux 中执行 ./gradlew build ，则会自动下载gradlew文件中指定的 Gradle 发行版。
如果我们想将 Gradle 包装器添加到我们的项目中：
gradle wrapper --gradle-version 4.2.1
该命令需要从项目的根目录执行。这将创建所有必要的文件和文件夹，以将 Gradle 包装器绑定到项目。另一种方法是将包装器任务添加到构建脚本中：
task wrapper(type: Wrapper) {
gradleVersion = '4.2.1'
}
现在我们需要执行包装器任务，该任务会将我们的项目绑定到包装器。除了gradlew文件之外，还会在gradle文件夹中生成一个wrapper文件夹，其中包含一个 jar 和一个属性文件。
如果我们想切换到新版本的 Gradle，我们只需要更改gradle-wrapper.properties中的一个条目。