1. 为什么我在 Quarkus 项目里从 Maven 切到了 Gradle
1.1 事情要从一次"又是 Maven 的问题"说起
先说背景。我之前用 Quarkus 写微服务,默认跟随官方文档走了 Maven。Quarkus 对 Maven 的支持相当成熟,文档齐全,社区里绝大多数示例都是 Maven 工程。按理说没有换工具的必要,直到我维护一个多模块项目,每个模块之间都有依赖,模块数量一多,Maven 的"全量重建"问题开始变得非常扎眼。
具体场景是这样的:我改了公共模块里的一个工具类,然后重新构建应用模块,Maven 会把整个 reactor 里相关的模块都重新跑一遍编译、测试、打包流程。如果只是本地开发,勉强能忍;一旦在 CI 上频繁跑构建,一次构建三五分钟起步,这个成本就很痛了。更难受的是,Quarkus 的开发模式(dev mode)虽然热重载做得好,但 Maven 在增量编译这块一直不太聪明——它不做内容哈希对比,只靠时间戳和文件状态来判断是否需要重编,改一个类经常触发大范围重编。
后来试了 Gradle,情况立刻不一样。Gradle 的增量构建和构建缓存机制是深度集成在任务图里的,它知道你的编译任务输入是哪些文件、输出是哪些 class 文件,只要文件内容没变,就算时间戳变了也照样跳过。这种"聪明"的程度,在 Quarkus 这种依赖大量注解处理和字节码生成框架上,体验差距是肉眼可见的。
1.2 Gradle 的三种能力正好补上 Quarkus 的短板
Quarkus 的构建过程有一个显著特点:它在编译期做大量工作,包括注解处理器生成字节码、构建 Jandex 索引、分析依赖、生成 native image 的中间产物。这些工作如果每次都从头跑一遍,构建时间会非常长。Gradle 的三种机制能精准地把这部分的成本降下来。
第一种是配置缓存(configuration cache)。Gradle 在 7.4 之后默认推荐开启配置缓存,它能把你整个构建脚本的配置阶段结果缓存下来,下次直接复用,只有任务执行阶段才真正跑。Quarkus 的构建脚本里有不少插件逻辑,配置阶段耗时不算短,配置缓存开了之后,构建启动明显轻快。
第二种是构建缓存(build cache)。本地缓存已经是好东西了,更狠的是远程构建缓存:团队里任何一个人构建过的产物,其他人直接拉取,编译这一步都省了。对 Quarkus 这种产物确定性较高的框架来说,远程缓存命中率相当可观。
第三种是守护进程(daemon)和并行执行。Gradle 默认起一个常驻的守护进程,JVM 不会反复启动,依赖解析的结果也在内存里缓存着。多模块项目里,独立模块间的任务可以并行跑,不比 Maven 那种"老老实实按依赖顺序排队执行"的方式,时间上能省一截。
我后来在团队里做了个简单对比:同一个多模块 Quarkus 项目,用 Maven 做一次全量 package,耗时约 3 分 20 秒;用 Gradle 冷构建首次约 2 分 40 秒,二次构建直接降到 40 秒以内。第二次构建因为增量构建和配置缓存生效,省掉了一大半活。这个差距在 CI 上滚一圈就能体会到,开发机上更是轻松不少。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Quarkus Gradle 插件环境准备与第一个项目
2.1 环境和版本组合的选择
开始之前先把版本关系说清楚。Quarkus 的 Gradle 插件从 Quarkus 2.x 时代开始就足够稳定了,到了 3.x 时代已经完全跟 Maven 插件平起平坐。目前主流组合是:
- JDK 17 或 21(Quarkus 3.x 要求 JDK 17+)
- Quarkus 3.x 最新稳定版
- Gradle 8.x(推荐 8.5 以上,配置缓存体验更好)
注意 Gradle 版本不是越新越好。Quarkus 插件对 Gradle 版本有一定的验证范围,比如 Quarkus 3.8 之前有些版本对 Gradle 8.6+ 的支持存在小问题,升级前最好看一眼 Quarkus 官方文档里 Gradle 兼容性表格。我自己吃过亏:当时图新鲜升级了 Gradle 8.10,结果 quarkusBuild 任务偶尔报一些奇怪的编译期错误,回退到 8.7 就好了,后面才确认是插件内部某个任务对 Gradle API 的兼容问题,等 Quarkus 版本更新后才解决。
另外,JDK 版本和 Gradle JVM 版本要区分开。Gradle 守护进程有自己运行的 JVM,项目编译也有自己的 Java 版本设置。如果你用 IDEA 打开项目,报 The project's Gradle version 8.5 is incompatible with the Gradle JVM version 21 之类的错误,多半是 Gradle 运行时 JVM 版本不合适。建议把 Gradle JVM 设置为 JDK 21,项目编译的 Java 版本设置为 17 或 21,两边不要混。我用的是 JDK 21 跑 Gradle 守护进程,项目本身编译目标 17,完全没问题。
2.2 生成项目的几种方式
Quarkus 官方推荐用 code.quarkus.io 网页生成项目,也可以装 Quarkus CLI 命令行生成,我两种都用过。网页端的优势是可视化选择扩展,勾选完直接下载 zip;CLI 的优势是方便集成进脚本,可以一条命令拉出一个带好扩展的项目。
我的建议是:就算你打算从零手写 build.gradle.kts,也不要真的从空文件开始。因为 Quarkus Gradle 插件需要依赖平台 BOM(Bill of Materials)来管理所有 Quarkus 扩展的版本,这个 BOM 的坐标和版本号手写容易出错。生成一个最基础项目,再在此基础上改,踩坑概率最低。
CLI 生成命令大概是:
bash复制quarkus create app com.example:demo-app --extension=resteasy-reactive,reactive-routes -b gradle
-b gradle 代表生成 Gradle 构建文件,不带这个参数默认是 Maven。生成完成后你会看到 `build.gradle.
