Ohhnews

分类导航

$ cd ..
foojay原文

Grails 框架未死：深入了解 Apache 基金会的重启之路

#grails#apache软件基金会#java开发#开源治理#软件现代化

目录

Steve Poole | 贡献者：James Fredley，Apache Grails 项目管理委员会 (PMC) 主席

对于许多人将其归类为“遗留项目”的技术而言，Grails 的活跃度高得令人意外。当整个行业的大部分注意力转向更新的框架和更时髦的技术栈时，幕后正在进行着一些更为深思熟虑的变革。

Grails 已经并入 Apache 软件基金会 (ASF)，正在经历现代化改造，并为下一个阶段蓄势待发。

如果你最近没有关注过 Grails，那么你对它的认知很可能已经滞后了几年。而这在很多方面正是问题的症结所在。

我们不再关注的技术

软件生态系统很少会突然消亡；大多数时候，它们只是逐渐淡出了人们的视野。会议议程不再提及，博客报道日益减少，新的框架占据了舆论高地。最终，我们集体“默认”某项技术已经“基本过时”。

但在企业环境中，事实往往并非如此。仍有许多 Grails 应用在生产环境中运行，处理着交易并服务于客户。然而，尽管系统依然存在，组织层面的关注点却已经转移。

在“炒作的热门技术”与“真正支撑互联网运行的技术”之间，存在着巨大的鸿沟。

根据 W3Techs 的数据，在已知服务器端语言的网站中，PHP 支撑了约 71.8% 的份额。仅 WordPress 一项就占据了整个互联网 40% 到 60% 的份额。

尽管 JavaScript 在会议圈中占据主导地位，但在服务器端，其占比却不足 6%。那些默默支撑互联网运行的技术，与那些占据舆论头条的技术，往往完全不是一回事。

为何加入 Apache 对 Grails 至关重要

Grails 向 ASF 的过渡不仅仅是行政上的整理。加入 ASF 旗帜下，是一个开源项目能够向外界传达其长期意图的最明确信号之一。

ASF 提供了一个中立的家园、可预测的发布准则，以及能够降低感知供应商风险的贡献者模式。

对于 Grails 而言，这一点至关重要，因为成熟平台的存亡取决于信任信号。此次加入 ASF 改变了企业在评估 Grails 是否仍有一席之地时的风险考量。

二十年的易手历程

这一背景使此次迁移更具意义。在 Grails 20 年的历史中，它在大部分时间里主要由单一组织领导：2005 年至 2008 年的 G2One，随后的 SpringSource（至 2015 年），Object Computing（至 2021 年），以及 Grails Foundation/Unity Foundation（至 2025 年）。

每一次过渡都带来了关于项目方向和可持续性的不确定性。

ASF 模式旨在打破这一循环，通过志愿者驱动的治理、供应商中立性以及“Apache 之道”所倡导的结构化透明度，取代对单一组织的依赖。

十八个月的迁移之路

2025 年 10 月，在经过 9 月份的董事会投票后，Grails 正式从孵化器毕业，成为 ASF 的顶级项目。

这听起来像是一个单一事件，但事实并非如此。这次迁移是一个长达 18 个月的过程，始于 2024 年春末，当时一个志愿者团队评估了项目的准备情况并提交了孵化提案。

随后是一项实质性的现代化工程：将仓库合并为单体仓库 (mono-repo)、彻底重构构建系统和依赖管理、升级 Maven 坐标，并在 ASF 治理下进行发布。第一个 ASF 版本（里程碑 4）于 2025 年 6 月发布，7.0.0 正式版于 10 月推出。

从一百个仓库到九个

仓库整合的规模本身就说明了问题。Grails 最初拥有约 100 个 Git 仓库，其中 43 个被列入 ASF 迁移计划。当迁移完成时，它们被整合为 18 个，目前仅有 9 个处于活跃使用状态。

这涉及了大量的底层改造。

单体仓库方法加速了与 ASF 政策的合规，但需要整合数百次提交中分离的构建系统和发布流程。

仅在 grails-core 单体仓库中就进行了超过 2,000 次提交，而发布构建时间从三周以上缩短到了约 30 分钟。

请再读一遍：从三周到 30 分钟。

代码之外：许可与合规

代码只是其中的一部分。团队还必须满足 ASF 的安全和许可要求。他们实现了可重现、可验证的构建（这需要向上游依赖项——包括 Apache Groovy——贡献代码）。

每一个源文件都经过了许可头检查，并对 327 个独立的制品进行了许可合规性审计。团队通过为每个发布的 jar 包采用软件物料清单 (SBOM) 实现了许可审查的自动化，确保在降低未来工作量的同时维持持续合规。

迁移完全自动化的 Gradle 和 GitHub 工作流本身就是一项新颖的挑战；其他在 ASF 的 Gradle 项目现在正将此成果作为参考实现。

你可能错过的现代化进程

大量的精心现代化工作集中在保持 Grails 与 JVM 和 Spring 生态系统的演进保持同步。

这绝非表面工程：依赖项已被更新，对较新 Java 运行时的兼容性也得到了加强。

Grails 7 带来了什么

Grails 7.0.0 于 2025 年 10 月发布，是 ASF 托管下的首个稳定版本。它带来了重大的依赖升级，包括支持 Java 17+（最高至 Java 25）、Groovy 4、Spring Boot 3.5、Spring Framework 6.2 和 Jakarta EE 10。

除了平台对齐外，该版本还引入了通过 Testcontainers 和 Geb 进行的容器化浏览器测试、可选的 Micronaut 集成、为所有已发布二进制文件生成的 SBOM，以及可重现的构建和制品。

grails-core 单体仓库现在在 109 个 Gradle 项目中产生超过 325 个已发布的 jar 文件，本地构建时间在两到十分钟之间，具体取决于缓存和硬件情况。

Grails 8 与发布节奏

Grails 8 的开发始于 2025 年 11 月下旬，紧跟该月底达到通用可用性的 Spring Boot 4.0。

该项目现在遵循 Spring Boot 的六个月发布节奏，每个版本提供 13 个月的支持。这为团队提供了可预测的时间表来规划工作。

重启背后的贡献者们

开源项目不会靠惯性演进。它们之所以前进，是因为有少数人认为这些工作值得去做。

Grails 今天面临的挑战之一不是缺乏活跃度，而是缺乏可见的叙事。

大部分工作集中在一小群坚定的维护者身上。从外部看，即使在取得实质性进展时，这看起来也可能像是一片沉寂。

为了让这些工作更透明，我采访了 Apache Grails PMC 主席 James Fredley，探讨了项目的现状和未来方向。

是什么促使 Grails 加入 Apache 软件基金会？

关于 Grails 的未来确实存在一些真实的疑问，这很正常。

在 4.x 到 6.x 版本期间，担忧逐渐增加，因为项目在多个组织间辗转，方向感模糊。在其 20 年的大部分历史中，Grails 主要由单一组织领导，社区贡献或投入有限。

加入 ASF 正是为了直接解决这个问题：从依赖单一组织转向志愿者驱动、供应商中立的模式。ASF 的结构——项目管理委员会、邮件列表、基于共识的投票、孵化过程——让人们相信该项目是可持续的，而不依赖于任何一家公司的优先事项。

从项目内部来看，进行了哪些技术工作？

其规模可能会让人们感到惊讶。数千小时的志愿者时间投入到了 7.x 线的现代化改造和向 8.x 的迈进中。

我们将大约 100 个仓库合并为 18 个（其中 9 个活跃），重写了构建和发布流水线，实现了可重现和可验证的构建，实施了 SBOM 生成，并确保了数百个制品的许可合规性。

Grails 7 现在在 109 个 Gradle 项目中产生超过 325 个 jar 包，本地构建时间在 2 到 10 分钟之间。发布过程本身从三周的苦差事变成了大约 30 分钟。

将我们完全自动化的 Gradle 和 GitHub 工作流迁移到 ASF 是一个新颖的挑战，但 grails-core 现在可以作为其他加入基金会的 Gradle 项目的模板。

人们还需要理解的是，Grails 应用本质上就是 Spring Boot 应用。

考虑到大约 85-90% 的 Java 应用运行在 Spring Boot 上，Grails 并不是什么异类：它只是在 Java 生态系统每个人都在使用的基础之上，增加了额外的开发者生产力层。

你希望 ASF 的过渡带来什么？

更广泛的采用和更广泛的贡献。ASF 为我们赢得了企业决策者的信任，他们需要确信一个框架在五年或十年后依然存在。

它也降低了新贡献者的门槛。治理是透明的，流程有据可查，项目也是真正受欢迎的。

Grails 现在遵循 Spring Boot 的发布节奏：六个月周期，13 个月支持，这为团队提供了可预测的规划时间表。

你最想纠正关于 Grails 的什么误解？

它是为遗留团队准备的遗留技术。

Grails 仍然是 Java 生态系统中构建 Web 应用最高效的方式，这应该吸引新工程师和新项目，而不仅仅是已有的存量系统。

“约定优于配置”的方法意味着更少的样板代码、合理的默认设置和温和的学习曲线。

它是一个“框架的框架”，构建在 Spring Boot、Spring Framework、Jakarta EE 和 Hibernate 之上。

如果你了解这些，你其实就已经掌握了 Grails 的重要部分。

2026 年 Grails 的真实定位

Grails 并没有试图在 Spring Boot 之上再去造一个 Spring Boot。它持续发挥价值的地方在于那些重视“约定重于配置”的生产力和快速交付的环境，特别是那些已经在 Groovy 生态系统中投入巨大的环境。

对于拥有现有 Grails 资产的团队来说，问题不在于“它还能用吗？”，而在于“留在这里还安全吗？”。

ASF 的毕业、Grails 7 的发布（支持 Java 17 到 25），以及紧跟 Spring Boot 4 的 Grails 8 的积极开发，都是为了降低这一决策的感知风险。但这种安全性取决于是否持续前行。

对于评估新项目的团队来说，生产力这一论点值得重新考虑。正如 Fredley 所言，Grails 是在 Java 生态系统 85-90% 的人已经在使用的技术之上，增加了额外的开发者生产力层。这种定位——不是“遗留框架”，而是“构建在 Spring Boot 之上的生产力加速器”——与大多数人脑海中固有的认知截然不同。

维持软件生命力的艰苦工作

软件很少因为单一的技术缺陷而死亡；它之所以消亡，是因为注意力转移到了别处。

目前的维护者们正在做的是确保一个成熟框架在快速变化的生态系统中保持活力所需的精细、系统性的工作。

在一个只崇尚新事物的行业中，这种工作以及它所必需的艰难的 EOL（生命周期终止）讨论，很容易被忽视。

这或许不应该被忽视。

当然，这些对于那些仍在服务器上运行 Grails 3 或 4 的团队来说并没有帮助。对他们而言，依赖关系的悬崖已经到来。在第二部分中，我想深入探讨那道悬崖究竟是什么样子，以及有哪些选择。

资源

作者注：

出于透明度考虑，我供职于 HeroDevs，这是一家为生命周期终止的开源组件提供扩展支持的公司。如果你目前正在评估旧版 Grails 资产的支持状况，了解 Java 生态系统中可用的持续支持选项是非常有价值的。过去几年，这一领域已经发生了显著演变。

这篇文章《Grails Isn't Done Yet (Part 1): Inside the ASF Reboot》最初发表于 foojay。