Gradle 的演进 - 与 Adam Murdoch 的对话

Calendar - Gradle 构建系统
Laura Kassovic
通用
Gradle 的 CTO Adam Murdoch 回顾了 Gradle 的发展历程，并对构建工具的未来项目和功能进行了展望。

目录

简介

我们与 Gradle 的 CTO Adam Murdoch 进行了一次对话，了解了他从 Gradle 的最初起源至今的历程。Adam 分享了对最新功能的见解，并讨论了构建工具的未来。

Gradle 的起源 #

Adam 大约在 2008 年开始了他的 Gradle 之旅，当时他正在寻找一种强大的替代方案来替代他当时使用的基于 Ant 的构建系统。他回忆说：“我当时正在寻找我们基于 Ant 的构建系统的替代品，偶然发现了这个名为 Gradle 的新工具，开始使用它，并开始发送补丁来改进它。”

Gradle 的创始人 Hans Dockter 认可了 Adam 的贡献，并邀请他作为维护者加入。这次合作标志着构建自动化领域变革之旅的开始。“15 年后的今天，我们仍然在这里，”Adam 回顾道，反思了自早期以来的巨大变化。

alt_text

认识到不断增长的生态系统 #

在回顾多年来构建工具的演变时，Adam 指出了生态系统的巨大扩展。“当我们开始使用 Gradle 时，还没有微服务 [...] 构建你的软件意味着编译一些类，进行一些调整，然后就完成了。”

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

  • 2012: Gradle 构建工具 1.0 引入了更快、更准确的依赖项解析引擎，并扩展了插件支持。
  • 2014: Gradle 构建工具 2.0 提高了性能和内存效率，引入了新的依赖项管理功能，并增强了增量构建支持。
  • 2016: Gradle 构建工具 3.0 默认启用 Gradle 守护程序，并通过 Kotlin DSL 增强了 IDE 支持，包括自动完成和导航。
  • 2016: Gradle, Inc. 发布了 Gradle Enterprise 作为商业产品，通过 Build Scan® 和 构建缓存，更好地、更快地构建软件。
  • 2017: Gradle 构建工具 4.0 使构建缓存可以用于 Java 和 Groovy 编译的生产环境，添加了丰富的控制台输出，并改进了增量编译。
  • 2018: Gradle 构建工具 5.0 将用于构建脚本的 Kotlin DSL 提升到生产就绪状态，支持 Java 11，添加了依赖项管理版本对齐，并改进了带有注解处理的增量编译。

支持更大的项目 #

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

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

专注于开发者生产力 #

在过去的五年中，Gradle 构建工具和 Develocity 工程师一直专注于通过以下方式提高开发者生产力：

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

无论是使用 Gradle 构建工具还是 Develocity，从构建中获得深入的见解都是“提高生产力的重要工具”。Adam 说，“一旦你知道问题所在，就很容易修复 [问题]。”

下一步是什么？ #

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

隔离项目 #

Adam 强调隔离项目 是 Gradle 中一项改变游戏规则的功能。这项开发专注于提高性能并显着减少构建期间的内存占用，承诺为管理单体仓库或大型项目的开发者带来实质性的好处。

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

请查看 隔离项目文档页面 以获取更多信息。

声明式 Gradle #

Adam 还提到了一个名为声明式 Gradle 的项目，该项目旨在使 Gradle 对软件开发者更加友好。其想法是，软件开发者应该能够升级依赖项、为他们的项目添加 Kotlin 支持或添加功能测试，而无需深入了解 Gradle。借助声明式 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 或通过 #releases-discussion 和 #declarative-gradle 频道在 Gradle 社区 Slack 上提供的任何反馈。

讨论

相关文章