管理任务

为了演示 DefaultTask 类的属性和方法，我将结合第 3 章中的 To Do 应用程序进行讲解。现在，您已经拥有了一般的构建基础架构，可以轻松添加功能。通常情况下，功能集被归类为版本。为了标识每个版本，我们会在交付产品中添加一个唯一的版本号。

许多企业或开源项目都有自己的版本控制策略。 回想一下您曾经参与过的一些项目。 通常，您分配特定的版本编号方案（例如，用点分隔的主要版本号和次要版本号，例如 1.2）。 您还可能会遇到附加 SNAPSHOT 指示符的项目版本，以指示构建的项目工件处于开发状态。 您已经在第 3 章中通过为项目属性 version 设置字符串值来为项目分配了版本。 使用字符串数据类型非常适合简单的用例，但是如果您想知道项目的确切次要版本怎么办？ 您必须解析字符串值，搜索点字符，并过滤掉标识次要版本的子字符串。 用实际的类来表示版本不是更容易吗？

您可以轻松地使用类的字段来设置、检索和修改编号方案的特定部分。 你还可以走得更远。 通过将版本信息外部化到持久数据存储（例如文件或数据库），您将避免修改构建脚本本身来更改项目版本。 图 4.4 说明了构建脚本、保存版本信息的属性文件和数据表示类之间的交互。 您将在接下来的部分中创建并学习如何使用所有这些文件。

您越想自动化项目生命周期，就必须能够以编程方式控制版本控制方案。 这是一个示例：您的代码已通过所有功能测试并准备好交付。 您项目的当前版本是 1.2-SNAPSHOT。 在构建最终的 WAR 文件之前，您需要将其设为发布版本 1.2 并自动将其部署到生产服务器。 其中每个步骤都可以通过创建任务来建模：一个任务用于修改项目版本，一个任务用于部署 WAR 文件。 让我们通过在项目中实施灵活的版本管理，将您对任务的了解提升到一个新的水平。

操作(action)是任务中放置构建逻辑的适当位置。 Task 接口为您提供了两个相关的方法来声明任务(action)操作：doFirst(Closure) 和 doLast(Closure)。 当任务执行时，定义为闭包参数的动作逻辑会依次执行。

您将通过添加一个名为 printVersion 的单个任务来轻松开始。 该任务的目的是打印出当前的项目版本。 将此逻辑定义为该任务的最后一个操作，如以下代码片段所示：

当使用 gradle printVersion 执行任务时，您应该看到正确的版本号：

通过使用 doFirst 方法，可以获得与任务的第一个操作相同的结果：

接下来，我们将改进输出版本号的方式。Gradle 提供了一个基于日志库 SLF4J 的日志记录器。除了常规的日志级别（DEBUG、ERROR、INFO、TRACE、WARN），它还增加了一些额外的级别。日志记录器实例可通过任务的方法之一直接访问。现在，我们将使用日志级别 QUIET 打印版本号：

看看访问任务属性之一是多么容易吗？ 我想向您展示另外两个属性： group 和 description。 两者都是任务文档的一部分。description 属性表示任务目的的简短定义，而 group 则定义任务的逻辑分组。 创建任务时，您将设置这两个属性的值作为参数：

看到访问其中一个任务属性是多么容易了吗？我还想向你展示另外两个属性： group 和 description。这两个属性都是任务文档的一部分。描述属性代表任务目的的简短定义，而组定义了任务的逻辑分组。在创建任务时，你可以将这两个属性的值设置为参数：

或者，您也可以通过调用 setter 方法来设置属性，如以下代码片段所示：

运行 gradle 任务时，您会看到该任务显示在正确的任务存储桶中，并且能够描述自身：

尽管设置任务的描述和分组是可选的，但为所有任务分配值始终是一个好主意。 它将使最终用户更容易识别任务的功能。 接下来，我们将回顾定义任务之间依赖关系的复杂性。

方法 dependsOn 允许声明对一个或多个任务的依赖关系。 您已经看到，Java 插件通过创建任务图来对完整任务生命周期（如构建任务）进行建模，从而广泛使用了这一概念。 以下清单显示了使用 dependsOn 方法应用任务依赖关系的不同方法。

您将通过从命令行调用第三个任务来执行任务依赖链：

如果您仔细查看任务执行顺序，您可能会对结果感到惊讶。 任务 printVersion 声明对第二个和第一个任务的依赖关系。 您难道没有预料到第二个任务会在第一个任务之前执行吗？ 在 Gradle 中，任务执行顺序是不确定的。

在实践中，您可能会发现自己遇到这样的情况：在执行依赖于某个资源的任务后需要清理该资源。 此类资源的典型用例是针对已部署的应用程序运行集成测试所需的 Web 容器。 Gradle 针对这种情况的解决方案是终结器任务，这些任务是计划运行的常规 Gradle 任务，即使终结任务失败也是如此。 以下代码片段演示了如何使用 Task 方法 FinalizedBy 来使用特定的终结器任务：

你会发现执行第一个任务会自动触发名为第二个的任务：

第 7 章借助真实示例更深入地介绍了终结器任务的概念。 在下一节中，您将编写一个 Groovy 类以允许对版本控制方案进行更细粒度的控制。

现在是时候回到我关于 Gradle 在构建脚本中定义通用 Groovy 代码的能力的声明了。 实际上，您可以按照在 Groovy 脚本或类中习惯的方式编写类和方法。 在本部分中，您将创建版本的类表示。 在 Java 中，遵循 bean 约定的类称为普通 Java 对象 (POJO)。 根据定义，它们通过 getter 和 setter 方法公开其字段。 随着时间的推移，手工编写这些方法会变得非常烦人。 POGO，Groovy 的 POJO 等价物，只需要您声明不带访问修饰符的属性。 它们的 getter 和 setter 方法本质上是在字节码生成时添加的，因此在运行时可用。 在下一个清单中，您分配 POGO ProjectVersion 的一个实例。 实际值在构造函数中设置。

运行修改后的构建脚本时，您应该看到任务 printVersion 生成与之前完全相同的结果。 不幸的是，您仍然需要手动编辑构建脚本来更改版本分类器。 接下来，您会将版本外部化到文件中并配置构建脚本来读取它。

在开始编写代码之前，您需要在构建脚本旁边创建一个名为 version.properties 的属性文件。 对于每个版本类别（例如主要版本和次要版本），您将创建一个单独的属性。 以下键值对代表初始版本 0.1-SNAPSHOT：

Gradle 通过比较两个构建之间任务的输入和输出的快照来确定任务是否是最新的，如图 4.6 所示。 如果自上次任务执行以来输入和输出没有更改，则任务被认为是最新的。 因此，任务仅在输入和输出不同时运行； 否则，它会被跳过。

输入可以是一个目录、一个或多个文件或任意属性。 任务的输出是通过目录或 1…​n 个文件定义的。 输入和输出被定义为类 DefaultTask 中的字段，并具有直接的类表示，如图 4.7 所示。

让我们看看这个功能的实际效果。 想象一下，您想要创建一个任务来为生产版本准备项目的可交付成果。 为此，您需要将项目版本从 SNAPSHOT 更改为发布版本。 以下清单定义了一个新任务，它将布尔值 true 分配给版本属性发布。 该任务还将版本更改传播到属性文件。

正如预期的那样，运行任务将更改版本属性并将新值保留到属性文件中。 以下输出演示了该行为：

任务 makeReleaseVersion 可能是将 WAR 文件部署到生产服务器的另一个生命周期任务的一部分。 您可能痛苦地意识到部署可能会出错。 网络可能出现故障，导致无法访问服务器。 修复网络问题后，您将需要再次运行部署任务。 由于任务 makeReleaseVersion 被声明为部署任务的依赖项，因此它会自动重新运行。 等等，您已经将项目版本标记为生产就绪，对吧？ 不幸的是，Gradle 任务不知道这一点。 为了让它意识到这一点，您将声明它的输入和输出，如下一个清单所示。

您将想要执行的代码移至 doLast 操作闭包中，并从任务声明中删除了左移运算符。 完成此操作后，您现在可以清楚地分离配置和操作代码。

现在，如果您执行任务两次，您将看到 Gradle 已经知道项目版本已设置为发布并自动跳过任务执行：

如果您不在属性文件中手动更改发布属性，则任务 makeReleaseVersion 的任何后续运行都将被标记为最新。

到目前为止，您已经使用 Gradle 的 DSL 在构建脚本中创建和修改任务。 每个任务都由在 Gradle 配置阶段为您实例化的实际任务对象提供支持。 在许多情况下，简单的任务就可以完成工作。 但是，有时您可能希望完全控制任务实施。 在下一节中，您将以自定义任务实现的形式重写任务 makeReleaseVersion。

任务 makeReleaseVersion 中的操作逻辑相当简单。 代码可维护性目前显然不是问题。 然而，在处理项目时，您会注意到，随着您需要添加的逻辑越多，简单的任务的规模就会迅速增大。 将出现将代码结构化为类和方法的需要。 您应该能够应用与常规生产源代码中所习惯的相同的编码实践，对吧？ Gradle 没有建议编写任务的特定方式。 您可以完全控制构建源代码。 您选择的编程语言（无论是 Java、Groovy 还是任何其他基于 JVM 的语言）以及任务的位置都由您决定。

自定义任务由两个组件组成：封装逻辑行为的自定义任务类（也称为任务类型）和为任务类公开的属性提供值以配置行为的实际任务。 Gradle 将这些任务称为增强型任务。

可维护性只是编写自定义任务类的优点之一。 因为您正在处理一个实际的类，所以任何方法都可以通过单元测试进行完全测试。 测试构建代码超出了本章的范围。 如果您想了解更多信息，请随时跳到第 7 章。增强任务相对于简单任务的另一个优势是可重用性。 自定义任务公开的属性可以从构建脚本中单独设置。 考虑到增强任务的好处，我们来讨论编写自定义任务类。

你还记得上一次人工生产部署出错的情景吗？我敢打赌，你的脑海中一定还浮现着一幅生动的画面：愤怒的客户给你的支持团队打电话，老板敲你的门询问出了什么问题，而你的同事则疯狂地试图找出启动应用程序时抛出堆栈跟踪的根本原因。在手动发布流程中，忘记一个步骤都可能是致命的。

让我们成为专业人士，并为构建生命周期各个方面的自动化而感到自豪。 能够以自动方式修改项目的版本控制方案只是对发布过程进行建模的第一步。 为了能够从失败的部署中快速恢复，良好的回滚策略至关重要。 事实证明，备份最新的稳定应用程序可交付成果以进行重新部署是非常有价值的。 您将使用 Gradle 附带的一些任务类型来为您的待办事项应用程序实现此过程的部分内容。

这就是你要做的事情。 在将任何代码部署到生产环境之前，您需要创建一个发行版。 它将作为未来失败部署的后备交付成果。 发行版是一个 ZIP 文件，包含 Web 应用程序存档、所有源文件和版本属性文件。 创建发行版后，文件将被复制到备份服务器。 备份服务器可以通过已安装的共享驱动器进行访问，也可以通过 FTP 传输文件。 因为我不想让这个示例太复杂而难以理解，所以您只需将其复制到子目录 build/backup 中即可。 图 4.8 说明了您希望执行任务的顺序。

有时您可能会发现自己编写了多个执行类似操作的任务。 例如，假设您想通过另外两项任务来扩展版本管理功能：一项是增加项目的主要版本，另一项是为次要版本分类器执行相同的工作。 这两个任务还应该保留对版本文件的更改。 如果您比较以下清单中两个任务的 doLast 操作，您可以发现您基本上重复了代码并对它们进行了微小的更改。

如果您在版本为 0.1-SNAPSHOT 的项目上运行 gradleincrementMajorVersion，您将看到版本已提升至 1.1-SNAPSHOT。 在 INFO 日志级别运行可以查看更详细的输出信息：

有两个单独的任务就可以了，但是您当然可以改进此实现。 最后，您对维护重复的代码不感兴趣。

您已经看到构建脚本代码的增长速度有多快。 在本章中，您已经在构建脚本中创建了两个 Groovy 类：ProjectVersion 和自定义任务 ReleaseVersionTask。 这些类是与项目一起移动到 buildSrc 目录的完美候选者。 buildSrc 目录是放置构建代码的替代位置，也是良好软件开发实践的真正推动者。 您将能够按照在任何其他项目中习惯的方式构建代码，甚至为其编写测试。

Gradle 标准化了 buildSrc 目录下源文件的布局。 Java 代码需要位于目录 src/main/java 中，而 Groovy 代码预计位于目录 src/main/groovy 中。 在这些目录中找到的任何代码都会自动编译并放入常规 Gradle 构建脚本的类路径中。 buildSrc 目录是组织代码的好方法。 因为您正在处理类，所以您也可以将它们放入特定的包中。 您将使它们成为 com.manning.gia 包的一部分。 以下目录结构显示了新位置中的 Groovy 类：

请注意，将类提取到自己的源文件中需要一些额外的工作。在构建脚本中定义类与在单独源文件中定义类的区别在于，你需要从 Gradle API 中导入类。下面的代码片段显示了自定义任务 ReleaseVersionTask 的包和导入声明：

反过来，您的构建脚本需要从 buildSrc 中导入已编译的类（例如 com.manning.gia.ReleaseVersionTask）。下面的控制台输出显示了在命令行上调用的任务之前运行的编译任务：

buildSrc 目录被视为其自己的 Gradle 项目，由路径 :buildSrc 指示。 由于您没有编写任何单元测试，因此会跳过测试的编译和执行任务。 第 7 章完全致力于为 buildSrc 中的类编写测试。

在前面的部分中，您了解了使用 Gradle API 提供的简单任务、自定义任务类和特定任务类型的详细信息。 我们研究了任务操作和配置代码之间的差异，以及它们适当的用例。 您学到的一个重要教训是，操作和配置代码是在构建生命周期的不同阶段执行的。 本章的其余部分将讨论如何编写在触发特定生命周期事件时执行的代码。