在入门教程中（构建脚本的基础识），已经学到了如何创建简单 task。之后您还学习了如何将其他行为添加到这些 task 中，同时你已经学会了如何创建 task 之间的依赖。这都是简单的 task 。但 Gradle 让 task 的概念更深远。Gradle 支持增强的task，也就是，有自己的属性和方法的 task 。这是真正的与你所使用的 Ant target（目标）的不同之处。
本章着眼于一些编写构建脚本的详细信息。构建语言Gradle 提供一种 domain specific language （领域特定语言）或者说是 DSL，来描述构建。这种构建语言基于 Groovy 中，并进行了一些补充，使其易于描述构建。构建脚本可以包含任何 Groovy 语言的元素（除了声明标签任何语言元素）。Gradle 假定每个构建脚本使用 UTF-8 编码。
除了支持传统的命令行界面，Gradle 也提供了一个图形化用户界面（GUI）。这是一个独立的用户界面，可以通过加上 --gui 选项来启动。Example 12.1. Launching the GUI gradle --gui注意：此命令行窗口被将锁定，直到 Gradle GUI 被关闭。如果是在 *nix 系统下，则可以通过 (gradle --gui&) 让它作为后台任务运行。
本章介绍了 Gradle 命令行的基本知识。正如在前面的章节里你所见到的， 调用 gradle 命令来执行构建。执行多 task同个构建可以执行多个 task ,通过再命令行 列出每个 task。举例，命令gradle compile test 将会执行 compile 和 test 两个 task。Gradle 将会按顺序执行 命令行每个列出的 task，并且执行每个 task 的依赖。
本章介绍了 Gradle 对 Web 应用的相关支持。 Gradle 为 Web 开发提供了两个主要插件,War 插件 和 Jetty 插件。 其中 War 插件继承自 Java 插件,可以用来生成 WAR 文件。Jetty 插件 继承自 War 插件 作为工程部署的容器。构建 WAR 文件应用 War 插件 来构建 WAR 文件：build.gradle apply plugin: 'war'注意，完整的项目源码见https://github.
使用 Groovy 插件来构建 Groovy 项目。这个插件继承自 Java 插件，使你的应用具备了编译能力。你的项目可以包含 Groovy 源码，Java 源码，或者两者都包含。在其他各方面，Groovy 项目与我们在快速开始 Java 中所看到的 Java 项目几乎相同 。一个基本的 Groovy 项目让我们来看一个例子。要使用 Groovy 插件，你需要在构建脚本文件当中添加以下内容build.
本章介绍一些 Gradle 依赖管理的基础什么是依赖管理大致上，依赖管理是由2块组成。首先，Gradle 需要知道项目构建或者运行的需要是东西。我们把引进的文件称之为 项目的依赖。其次，Gradle 需要构建和上传项目的产物。我们把向外输出的文件称之为项目的发布。现在看下细节：很多项目不能完全自我包含。他们需要其他项目的产物。
关于 Java 插件Gradle 是一个通用的构建工具，它能构建任何基于你的构建脚本的东西。开箱即用，当然除非你添加代码到你的构建脚本里，不然它不会构建任何东西。很多 Java 项目都有类似的基本流程：编译 Java 源文件，运行单元测试，创建 JAR 文件。如果你不是把代码从头写到尾，那还能接受。现在有了 Gradle 就不用忍受这些。解决问题的方法就是 插件。
在 Gradle 中两个顶级概念：project（项目）和 task （任务）所有 Gradle 都有一个或多个 project 构成。project 的展现取决于 Gradle 所做的工作。举例。 project 可以是一个 JAR 库 或者是 web 应用。它可以是由项目生产 JAR 组成发布的 ZIP。一个 project 不一定代表一个东西要构建。它可能是一件要做的事，如将应用程序部署到工作台或生产环境。
Sonar runner 插件是目前仍是孵化状态。请务必注意，在以后的 Gradle 版本中，DSL 和其他配置可能会有所改变。 Sonar Runner 插件提供了对 Sonar，一个基于 web 的代码质量监测平台的集成。它基于 Sonar Runner，一个分析源代码及构建输出，并将所有收集的信息储存在 Sonar 数据库的 Sonar 客户端组件。
一些开源的测试框架比如JUnit,TestNG能够帮助你编写可复用的结构化的测试，为了运行这些测试，你要先编译它们，就像编译源代码一样。测试代码的作用仅仅用于测试的情况，你可不想把你的测试代码发布到生产环境中，把源代码和测试代码混在一起可不是个好主意。通常你会把源代码和测试代码分开来，比如Gradle的标准项目布局src/main/java和src/test/java。
Gradle构建脚本的标准名称是build.gradle，在一个多项目构建的环境中，你想自定义你的构建脚本名称来显得高大上一点，因为多个项目有相同的构建脚本名称可能会混淆，接下来介绍如何使用自定义的脚本名称。
到目前为止我们自定义了一个build.gradle和settings.gradle文件，随着你添加越来越多的子项目和任务到build.gradle中，代码的维护性将会下降。通过给每个子项目建立一个单独的build.gradle文件可以解决这个问题。接下来我们在每个子项目的目录下创建一个build.gradle文件，目录如下：现在你可以把构建逻辑从原先的build脚本中拆分开来放到合适的位置。
到目前为止你已经把ToDo项目根据功能拆分成多个模块，接下来可以用之前的方法来定义构建逻辑，下面有几点需要主要：根目录和子目录使用相同的group和version属性值所有的子目录都是Java项目需要Java插件来正常工作，所以你只需要在子项目中应用Java插件web子项目是唯一一个依赖外部库的项目，它需要打包成WAR而不是JAR子项目之间可以定义模块依赖接下来你将学习如何定义…
上一节你给你的项目定义了一个层次化的目录结构，整个项目包含一个根目录和每个模块一个子目录，这一节你将学习怎么用Gradle来构建这样一个项目结构。首先在你的根目录新建一个build.
在企业项目中，包层次和类关系比较负责，把代码拆分成模块是一个比较困难的任务，因为这需要你清晰的划分功能的边界，比如把业务逻辑和数据持久化拆分开来。解耦和聚合但你的项目符合高内聚低耦合时，模块化就变得很容易，这是一条非常好的软件开发实践。
Gradle支持下面三种不同类型的仓库：下图是配置不同仓库对应的Gradle API：下面以Maven仓库来介绍，Maven仓库是Java项目中使用最为广泛的一个仓库，库文件一般是以JAR文件的形式存在，用XML(POM文件)来来描述库的元数据和它的传递依赖。所有的库文件都存储在仓库的指定位置，当你在构建脚本中声明了依赖时，这些属性用来找到库文件在仓库中的准确位置。
DSL配置block dependencies用来给配置添加一个或多个依赖，你的项目不仅可以添加外部依赖，下面这张表显示了Gradle支持的各种不同类型的依赖。这一章直接扫外部模块依赖和文件依赖，我们来看看Gradle APi是怎么表示依赖的。
在前面我们学习了怎么使用Jetty插件来使用自带的Jetty容器来部署一个TODo应用，Jetty是一个轻量级的开发容器，启动非常快。很多企业级的应用都使用其他的Web容器来部署应用，假设你使用的是Apache Tomcat。
几乎所有基于JVM的项目都会或多或少依赖其他库，假设你在开发一个基于web的项目，你很可能会依赖很受欢迎的开源框架比如Spring MVC来提高效率。Java的第三方库一般以JAR文件的形式存在，一般用库名加版本号来标识。随着开发的进行依赖的第三方库增多小的项目变的越来越大，组织和管理你的JAR文件就很关键。
关注时代Java
