Gradle 依赖图的真实示例有哪些？

Question

正如文档中所述，Gradle 使用有向无环图 (DAG)构建依赖图。根据我的理解，具有单独的评估和执行周期是构建工具的一个主要功能。例如 Gradle 文档 声明这可以实现一些原本不可能实现的功能。

我对展示此功能强大功能的现实示例感兴趣。依赖图对于哪些用例很重要？我对来自该领域的个人故事特别感兴趣，无论是使用 Gradle 还是类似装备的工具。

我从一开始就制作这个“社区维基”，因为很难评估“正确”的答案。

Answer 1

这个具有挑战性的问题为最终研究 Gradle 提供了动力。我还没有使用过它，所以我只能提供浏览文档时记录的分析，而不是个人故事。

我的第一个问题是为什么 Gradle 任务依赖图保证是非循环的。我没有找到答案，但很容易构建相反的情况，因此我假设循环检测是构建图时运行的验证，并且在执行第一个任务之前构建失败，如果存在非法循环依赖。如果不首先构建图表，则在构建接近完成之前可能不会发现这种故障情况。此外，检测例程必须在每个任务执行后运行，这将是非常低效的（只要图是增量构建的并且全局可用，则只需要深度优先搜索来找到起点，然后周期评估只需要很少的工作，但总的工作量仍然比一开始就对整个关系集进行一次缩减要大）。我认为早期检测是一个主要好处。

任务依赖关系可以是惰性的（请参阅：4.3 任务依赖关系，以及 13.14 中的相关示例）。在构建整个图之前，无法正确评估惰性任务依赖关系。对于传递（非任务）依赖项解析也是如此，这可能会导致无数问题，并且在发现和解决其他依赖项时需要重复重新编译（还需要对存储库重复请求）。任务规则功能（13.8）也是不可能的。这些问题以及可能的许多其他问题可以通过考虑 Gradle 使用动态语言来概括，并且可以动态添加和修改任务，因此在首次通过评估之前，结果可能是不确定的，因为执行路径是构建的并且因此，如果存在直到以后才知道的依赖项或行为指令（因为它们尚未创建），则不同的评估序列可能会产生任意不同的结果。 （这可能值得用一些具体的例子来研究。如果这是真的，那么即使两次传递也并不总是足够的。如果 A -> B，B -> C，其中 C 改变了 A 的行为，使得它不再依赖于 B，那么我希望有一些限制非局部范围元编程的最佳实践，以不允许它出现在任意任务中，一个有趣的例子是时间旅行悖论的模拟，其中。孙子杀死了他的祖父或娶了他的祖母，生动地说明了一些实用的道德原则！）

它可以更好地报告当前正在执行的构建的状态和进度。 TaskExecutionListener 为每个任务的处理提供了 before/after 挂钩，但在不知道剩余任务数量的情况下，除了“6 个任务已完成。即将执行任务 foo”之外，它无法说明其他状态。相反，您可以使用 gradle.taskGraph.whenReady 中的任务数初始化 TaskExecutionListener，然后将其附加到 TaskExecutionGraph。现在它可以提供信息来启用报告详细信息，例如“已完成 72 个任务中的 6 个。正在执行任务 foo。预计剩余时间：2 小时 38 分钟。”这对于在持续集成服务器的控制台上显示非常有用，或者如果 Gradle 用于编排大型多项目构建并且时间估计至关重要。

正如 Jerry Bullard 所指出的，生命周期的评估部分对于确定执行计划至关重要，执行计划提供有关环境的信息，因为环境部分由执行上下文决定（通过 DAG 配置部分中的示例 4.15）。此外，我发现这对于执行优化很有用。独立的子路径可以安全地传递给不同的线程。如果执行的步行算法不是天真的的话，那么它们的内存密集程度可能会较低（我的直觉是，总是走具有最多子路径的路径将导致比总是首选具有最少子路径的路径产生更大的堆栈）。

一个有趣的用途可能是系统的许多组件最初被删除以支持演示和增量开发的情况。然后在开发过程中，构建本身可以确定子项目是否已准备好包含（也许它会尝试获取代码，编译它并运行预先确定的测试套件），而不是在实现每个组件时更新构建配置。如果是，评估阶段将揭示这一点，并且将包括适当的任务，否则，它会选择存根的任务。也许对 Oracle 数据库的依赖尚不可用，而您同时正在使用嵌入式数据库。您可以让构建检查可用性，在可以时透明地切换，并告诉您它切换了数据库，而不是您告诉它。沿着这些思路，可能会有很多创造性的用途。

Gradle 看起来棒极了。感谢您引发一些研究！

Answer 2

同一文档中的示例说明了这种方法的力量：

正如我们稍后详细描述的
（参见第 30 章，构建生命周期）
Gradle 有一个配置阶段
执行阶段。之后
配置阶段 Gradle 无所不知
应该执行的任务。摇篮
为您提供一个钩子来利用它
信息。这样做的一个用例是
是检查发布任务是否
需要执行的部分任务。
根据这个你可以分配
某些变量的值不同。

换句话说，您可以尽早加入构建过程，这样您就可以根据需要改变其过程。如果已经执行了一些实际的构建工作，那么更改可能为时已晚。

Answer 3

我现在正在评估不同的构建系统，并使用 gradle 设法添加丑陋的代码，枚举“jar”类型的所有任务并更改它们，以便每个 jar 清单都包含“Build-Number”属性（稍后用于组成最终的文件名）：

gradle.taskGraph.whenReady {
    taskGraph ->
    taskGraph.getAllTasks().findAll {
        it instanceof org.gradle.api.tasks.bundling.Jar
    }.each {
        it.getManifest().getAttributes().put('Build-Number', project.buildVersion.buildNumber)
    }
}