一，gradle的定义
1，gradle是基于Apache Maven概念的项目自动化构建开源工具。他是使用一种基于groovy的 特定领域语言来声明项目配置，抛弃了 基于 XML的各种繁琐配置。
虽然gradle都是基于groovy的，但是由于其提供了一整套DSL，所以在开发gradle脚本时几乎脱离了groovy的感知。我们在这里将gradle当做一个独立的部署工具。因此不去深究，因为这个对于我们去了解gradle并没有多大的的问题。
2，gradle项目领域
每个项目都会有自己的gradle领域，配置脚本文件名默认是不变的build.gradle。
project之间如果出现父子关系，只有根project的build.gradle才会有setting.gradle配置文件，该配置文件的作用的声明其包含的子项目。
3，Task任务
每个project是由N个Task组织成的一个“有向无环图”，task之间有依赖关系从而决定了他们的执行顺序。
依赖方式：
task taskA（ dependsOn : 'taskB')<<{
println 'task'
}Task的三种来源以及创建方式
第一种就是gradle默认自带了几种task
Dependencies：显示所有Project（项目）的依赖信息
Projects：显示所有Project，包括根project以及子project。
Properties:显示一个Project所包含的所有Property
第二种就是直接在project中显式创建
hello << {
println ' Hello Task'
}第三种直接是成品Task的方式进行引入
通过Apply方式引入，表达方式为Apply plugin：‘groovy’
proprety：属性
Project不仅包含Task而且还包含；property这个属性，，property磨人自带了一些属性而且同时也可以通过扩展ext的方式进行自定义扩展属性。
gradle的工作流程
一次的gradle工作流分为三大部分，主要是
（1）解析setting.gradle文件然后去遍历根目录，检查子项目是否满足规定。
（2）解析每个子project的gradle，然后根据Task去构建项目之间的有向无环图。
（3）直接执行，涉及到刷新下载依赖，以及build构建发布包等等。
gradle脚本详解-- 单project项目的文件详解
buildscript {
repositories {
jcenter()
maven { url "https://plugins.gradle.org/m2/" }
}
dependencies {
classpath 'com.netflix.nebula:gradle-netflixoss-project-plugin:5.1.1-rc.1'
}
}
apply plugin: 'nebula.netflixoss'
apply plugin: 'groovy'
apply plugin: 'idea'
group = 'com.netflix.spinnaker.gradle'
sourceCompatibility = 1.8
targetCompatibility = 1.8
idea {
project {
jdkName = sourceCompatibility
languageLevel = targetCompatibility
vcs = 'Git'
}
}
bintray {
pkg {
userOrg = 'spinnaker'
repo = 'gradle'
labels = ['Spinnaker', 'Netflix']
}
}
repositories {
jcenter()
maven { url "https://plugins.gradle.org/m2/" }
}
dependencies {
compile gradleApi()
compile localGroovy()
compile 'com.netflix.nebula:gradle-netflixoss-project-plugin:5.1.1-rc.1'
compile 'com.netflix.nebula:gradle-ospackage-plugin:4.9.3'
compile 'com.jfrog.bintray.gradle:gradle-bintray-plugin:1.8.1'
compile 'org.yaml:snakeyaml:1.17'
}gradle文件的结构详解
buildscript：因为gradle本身也是groovy语言，所以脚本一开始要为gradle准备好执行环境。
repositories：仓库地址，这里配置了两个仓库jcenter和maven，我们先解释下两者的区别和联系。jcenter和maven分别是JFrog和Sonatype公司提供的仓库服务，jcenter的优点是因为采取了CDN技术所以获取非常迅速；maven的优点是仓库内容比jcenter要全面，在jcenter中找不到的内容可以在maven中找到。也正是因为这两个仓库各自的优缺点才有了你所看到的脚本中配置的先后顺序（gradle寻找依赖包是按照脚本书写的先后顺序来执行的）。Gradle默认不提前定义任何仓库，我们必须手动在使用外部依赖之前定义自己的仓库
一个项目可以有好几个库，Gradle会根据依赖定义的顺序在各个库里寻找它们，在第一个库里找到了就不会再在第二个库里找。
apply plugin：task的第三类引入-插件式
dependencies：具体的依赖包，可以看到在buildscript中出现一次，在脚本结尾出现一次。buildscript中出现是因为它是gradle执行的依赖（classpath指定）；第二次出现时项目本身的依赖（compile指定）。
repositories：同dependencies一样在buildscript内外各出现一次，分别是gradle脚本的依赖和项目本身的依赖。
bintra：这个task坑较多，目的是将最终的项目发布到jcenter中，里面配置了组织名、仓库名等信息。
compile：用来编译项目源代码的依赖，先看最后4行，他们的格式是group:name:version，很好理解。gradleApi()和localGroovy()这两行并没有按照我们所说的group:name:version的格式，这是干什么用的么？我们需要再学习下“自定义plugin”，详见下一章节。
与build.gradle平级目录还需要一个settings.gradle，该项目只有一行：
rootProject.name = ‘spinnaker-gradle-project’
指明编译的根项目。
注意要点：
1，其实不管是project还是module都是一个project。只是project对应根目录·下的project。
2，而module对应的是子目录下project。也就是子project。
3，module与project他们每个项目都是对应build.gradle。
4, 如果把build.gradle删除，那么出现的状况就是module就不再是一个project项目了。
5，buildscript{}设置脚本的运行环境。
repositories{}支持java依赖库管理，用于项目依赖。
dependencies{}依赖包的定义。支持maven/ivy，远程，本地库，也支持单文件。如果前面定义了repositories{}maven 库，则使用maven的依赖库，使用时只需要按照用类似于。com.android.tools.build:gradle:0.4，gradle 就会自动的往远程库下载相应的依赖。
