Gradle 的演变 - 与 Adam Murdoch 的对话

Calendar - Gradle 构建系统
Laura Kassovic
通用
Gradle 的首席技术官 Adam Murdoch 分享了他对 Gradle 的历史回顾，并预告了这款构建工具的未来项目和功能。

目录

引言

我们与 Gradle 的首席技术官 Adam Murdoch 进行了一场 对话，谈论了他从 Gradle 诞生之初的经历。Adam 分享了他对最新功能的见解，并讨论了构建工具的未来。

Gradle 的起源 #

Adam 在 2008 年左右开始接触 Gradle，当时他正在寻找一种比他当时使用的基于 Ant 的构建系统更强大的替代方案。他回忆道：“我当时正在寻找一个替代我们基于 Ant 的构建系统的工具，偶然发现了这个名为 Gradle 的新工具，开始使用它，[并且] 开始提交补丁以进行改进。”

Gradle 的创始人 Hans Dockter 认可了 Adam 的贡献，并邀请他加入成为维护者。这次合作标志着构建自动化领域变革性旅程的开始。“十五年过去了，”Adam 感叹道，回顾了早期以来的巨大变化。

alt_text

认识到不断壮大的生态系统 #

Adam 回顾了多年来构建工具的演变，他注意到生态系统的急剧扩张。“当我们开始使用 Gradle 时，还没有微服务……构建你的软件意味着编译一些类，进行一些调整，然后就完成了。”

如今，情况已大不相同。构建工具现在需要处理从部署到生产的各种任务，而这些任务在 Gradle 刚开始时并未被考虑在内。Kotlin 等语言以及 Android 等平台的出现，进一步扩展了 Gradle 在开发者社区中的作用。

  • 2012：Gradle Build Tool 1.0 引入了更快、更准确的依赖解析引擎，并扩展了插件支持。
  • 2014：Gradle Build Tool 2.0 提高了性能和内存效率，引入了新的依赖管理功能，并增强了增量构建支持。
  • 2016：Gradle Build Tool 3.0 默认启用了 Gradle Daemon，并通过 Kotlin DSL 的自动补全和导航增强了 IDE 支持。
  • 2016：Gradle, Inc. 发布了 Gradle Enterprise 作为商业产品，通过 Build Scan® 和 Build Cache 来构建更好、更快的软件。
  • 2017：Gradle Build Tool 4.0 使构建缓存对 Java 和 Groovy 编译生产就绪，增加了丰富的控制台输出，并改进了增量编译。
  • 2018：Gradle Build Tool 5.0 将 Kotlin DSL 用于构建脚本推广为生产就绪，支持 Java 11，增加了依赖管理版本对齐，并通过注解处理改进了增量编译。

支持更大的项目 #

Adam 指出，构建工具的范围已经扩大，软件项目的规模也呈指数级增长。“每个团队每年都在生产越来越多的软件，”他说，强调了提高性能以满足日益增长的需求的持续挑战。这种可扩展性至关重要，Adam 提到 Gradle 一直专注于通过解决配置模型中的基本限制来克服历史性的扩展问题。

  • 2019：Gradle Build Tool 6.0 引入了增强的依赖管理功能和新的元数据格式，并通过更新的生态系统插件和 API 提高了开发人员的生产力。
  • 2021：Gradle Build Tool 7.0 提供了更快的增量构建，通过依赖项完整性验证增强了安全性，并支持 Java 16。
  • 2023：Gradle Build Tool 8.0 首次推出了配置缓存，增强了并行性以加快构建速度，并改进了 Java 编译。
  • 2023：Gradle, Inc. 将 Gradle Enterprise 更名为 Develocity，以强调其对构建工具的通用方法。Develocity 当然支持 Gradle，但也支持 Bazel、SBT 和 Maven。它还引入了两项主要功能：Test Distribution 和使用 ML（机器学习）的 Predictive Test Selection。

关注开发人员的生产力 #

在过去的五年里，Gradle Build Tool 和 Develocity 的工程师们一直致力于提高开发人员的生产力，具体做法是：

  • 强调 **快速反馈循环** 和 **早期错误检测** 的重要性。
  • 量化 **与低生产力环境相关的成本**。
  • 通过 **利用缓存等加速技术** 来改进开发流程。
  • 利用数据主动 **提高开发工具链的可靠性**。
  • 识别并 **消除频繁出现的错误** 和诸如不稳定测试之类的嘈杂信号。

Adam 表示，无论是使用 Gradle Build Tool 还是 Develocity，从构建中获得深入的见解“是提高生产力的重要工具”。“一旦你发现了问题，就很容易修复它们。”

下一步是什么？ #

Adam 目前的重点是 *声明式 Gradle* 和 *隔离的项目*，以提高 Gradle 的可用性。“历史上，Gradle 的受众一直是构建工程师……我们正在将焦点转移到软件开发者身上。”

隔离的项目 #

Adam 强调 *隔离的项目* 是 Gradle 中一项具有变革意义的功能。这项开发工作专注于提高性能并显著降低构建过程中的内存占用，有望为管理单体仓库或大型项目的开发人员带来巨大的好处。

启用 *隔离的项目* 后，Gradle 项目的配置模型会彼此“隔离”。这意味着构建逻辑（例如构建脚本或应用于项目的插件）无法直接访问另一个项目的可变状态。这种隔离使得每个项目的配置和工具模型创建可以安全地并行运行，并且结果可以独立地为每个项目进行缓存和失效。

有关更多信息，请查看 隔离的项目文档页面。

声明式 Gradle #

Adam 还提到了一个名为 *声明式 Gradle* 的项目，该项目旨在使 Gradle 对软件开发者更加友好。其理念是，软件开发者应该能够在无需深入了解 Gradle 的情况下，升级依赖项、为项目添加 Kotlin 支持或添加功能测试。通过 *声明式 Gradle*，开发人员还将受益于更好的工具支持，尤其是在 IDE 中，通过自动化软件定义的变化。

alt_text

通过 *声明式 Gradle*，构建定义以一种高层次的、描述性的方式表达，而不是通过命令式代码和构建逻辑。软件开发者通过使用声明式 DSL 表达的软件类型进行交互，以描述需要构建的内容，包括软件的语言、目标平台、依赖项和质量检查，而无需深入了解如何构建该软件。

androidLibrary {
  namespace = "com.google.samples.apps.nowinandroid.core.common"
  dependencies {
    implementation("org.jetbrains.kotlinx:kotlinx-coroutines:1.7.3")
    implementation("app.cash.turbine:turbine:1.0.0")
  }
  buildTypes {
    debug {}
    release {}
  }
}

使用声明式 DSL 不可能实现诸如控制流之类的编程结构。这清楚地区分了软件定义和构建逻辑，使开发人员能够专注于用熟悉的术语描述他们的软件，而构建工程师则在插件中处理底层的实现细节。这种方法确保了一个更清晰、更直观、更易于维护的构建过程。

了解更多关于声明式 Gradle：#

*声明式 Gradle* 是一个正在积极开发的实验性项目。目前不保证兼容性，并且尚未准备好投入实际使用。DSL 语法或可用功能均无任何承诺。我们 预计 在 2024 年年中发布第一个早期访问预览版 (EAP)，以收集有关项目方向的反馈。

至于 Adam，他说：“对于 *隔离的项目* 和 *声明式 Gradle* 的成功来说，获得人们的反馈至关重要。” 我们非常感谢通过 GitHub issue 或在 Gradle 社区 Slack 上的 `#releases-discussion` 和 `#declarative-gradle` 频道提供的任何反馈。

讨论

相关帖子