Maven 4.0.0正式发布的那个消息我是先在技术群里看到的。转发的人配了一句“爷青结”底下评论区一半在问“和Gradle比到底谁强”另一半在问“咱们那堆老项目能不能直接升”。作为一个从Maven 2时代一路build过来的老Java开发我的第一反应不是激动而是“终于”。Maven这个构建工具在Java生态里扛了十五年扛住了Gradle的冲击扛住了各种“XX已死”的论调但它自己也攒了一身的技术债。标题里说的“彻底重构”不是营销话术——这次不是把版本号从3跳到4那么简单而是官方把2009年那套“为了兼容而兼容”的老内核真正动了一次大手术。这篇文章不打算翻译release notes也不打算替Maven官网吹牛。我就以一个实际写代码、配构建、被构建工具折磨过无数次的一线开发者视角聊清楚三件事Maven 4到底改了什么、从Maven 3迁移过去要做哪些事、以及它和Gradle的竞争现在到底是什么局面。不管你是维护着一个几十个模块的遗留系统还是刚在新项目里犹豫选什么构建工具这篇都值得你花十分钟看完。1. Maven的十五年那套“老设计”为什么一直没被淘汰1.1 从Maven 1到Maven 3它赢在“约定”而不是“技术”很多人现在吐槽Maven的XML配置啰嗦但回到2005年前后Java项目构建的真实状况比这混乱得多。那时候Ant是主流每个团队都在写自己的target脚本同一个项目换个新人接手光看懂build.xml里的依赖关系就要半天。Maven 1其实没解决这个问题直到Maven 2提出了“约定优于配置”这个核心思想目录结构固定、生命周期固定、依赖通过坐标声明你不需要告诉构建工具“先编译再打包”你只需要说“我要package”Maven自己就知道该干什么。这套设计在当年是降维打击。它把构建从“写脚本”变成了“填配置”让Java项目的结构有了统一规范。Maven 3在2010年发布主要解决的是性能问题和部分可用性问题比如并行构建、更好的依赖解析。但Maven 3的主体架构还是Maven 2的延续所以准确地说从Maven 2时代算起那套核心设计确实已经运行了十五年以上。Gradle在这期间靠着更灵活的脚本和更快的增量构建抢走了不少用户尤其在Android和Java后端新项目里但Maven始终没有退出牌桌靠的就是庞大的存量生态和“稳定压倒一切”的标签。1.2 老架构欠下的技术债比想象中严重作为一个老用户我对Maven的感情很复杂。它确实可靠但那些年踩过的坑也是一言难尽。最痛苦的是插件生态的老化。Maven的插件API长期暴露了大量内部实现类插件作者想实现一个稍微复杂点的功能就不得不直接依赖maven-core里的类。结果就是Maven每升一个大版本总有一批老插件跟着报NoSuchMethodError或者ClassNotFoundException你得满世界找新版本或者干脆自己改插件。然后是构建速度。Maven 3默认是串行构建的一个几十个模块的项目clean package跑个七八分钟是常事。虽然可以开-T 4并行但老项目里模块之间隐式依赖太多一开并行就各种奇怪的问题。再就是POM的复杂度一个稍微正式点的项目pom.xml动辄两三百行里面还有大量是为了兼容老版本而存在的废弃标签。这些“屎山”不是用户不想清理而是清理了可能触发某些老插件行为改变没人敢动。时间长了整个构建体系就像一座老房子水管电线都老化了但因为一直住着人谁也不敢随便拆墙。1.3 “彻底重构”的准确含义换引擎不换方向盘Maven 4官方说的“彻底重构”很多人误以为是把源码重写一遍。实际不是也不可能是。Maven的存量用户太多了如果搞一个完全不兼容的新工具那等于把市场份额直接让给Gradle。Maven 4的做法是保留“坐标、生命周期、插件”这三大基石不动把底下那层老旧的实现全部换掉。具体来说它引入了一套新的稳定API包org.apache.maven.api把插件依赖的内部实现类逐渐隔离出去换了新的依赖解析引擎优化了下载和解析性能改了构建输出的组织方式为增量构建做准备重写了启动脚本让Maven本身启动更快。你可以这么理解方向盘、油门、刹车的位置都没变但发动机、变速箱、电路系统全换成了新的。老司机上车不用重新学但开起来会发现比以前轻快很多。2. Maven 4的核心变化哪些会真正影响你的日常2.1 POM配置在悄悄“减肥”但不影响老手习惯Maven 4的第一个直观变化是POM可以写得更短了。官方做了很多默认值的优化比如子模块的groupId和version如果和父POM一致可以在子模块里直接省略只保留artifactId。还有一些已经废弃多年的标签在这次版本里被正式清理掉了——注意是“正式”在Maven 3时代它们只是标记为deprecated你写上也不会报错只是警告所以大家就都懒得删。到了Maven 4这部分历史包袱被直接扫地出门。如果你之前写的POM清清爽爽那升级基本没有感知。如果你是那种“能用就行警告从来不看的”类型那升级后可能发现某些标签真的不能用了需要动手删一下。我的建议是迁移前先用mvn help:effective-pom生成一份完整的有效POM存个档万一删错了标签还能对着这份文件找回原来继承的配置。这招在Maven 3时代就是排查配置问题的利器到了Maven 4依然是最实用的操作没有之一。这里提醒一句POM减肥只是“可以瘦”不是“必须瘦”。Maven 4对老POM的兼容性做得还是比较到位的你保留原来那种写全groupId、version的写法也完全没问题。追求简洁是给新项目用的老项目能不动就不动这是迁移的第一原则。2.2 依赖解析引擎升级下载和构建都变快Maven被吐槽最多的一点就是慢而慢的很大一部分原因在依赖解析。Maven 3的解析器在遇到复杂的传递依赖时经常要做大量重复计算。Maven 4换了一套新的解析引擎在解析策略上做了优化特别是对传递依赖的冲突处理有了更清晰的模型。从官方公布的benchmark数据来看纯解析阶段的性能提升是比较明显的当然我个人的体感是第一次全量构建的提升没有传说中那么夸张但第二次往下走增量构建的速度提升确实能感受到。另外一个容易被忽略但很重要的变化是下载模块的重写。老版本Maven在下载依赖时用的是比较老旧的HTTP客户端逻辑连接复用和重试机制都不够好内网镜像或者网络不稳定的时候动不动就卡在“Downloading”半天不动。Maven 4底层换成了新版Resolver对连接管理和并行下载都做了优化。配合上国内常用的阿里云镜像仓库mvn compile的体感会比Maven 3时代顺滑不少。如果你还在用默认中央仓库裸奔那我建议无论如何都先配好镜像这个操作能解决一半的构建速度问题。2.3 构建路径隔离和多版本JAR多模块项目的福音这次重构里我自己最看重的是构建输出路径的变化。以前的Maven多模块项目每个模块的target目录之间虽然逻辑上独立但在一些特殊操作比如模块间直接引用另一个模块的target/classes时容易互相干扰。Maven 3时代很多项目的构建脚本喜欢写相对路径去拿别的模块的编译产物这种做法在Maven 4里被默认的行为所隔离。官方在Maven 4里做了“构建隔离”的处理每个模块的构建过程状态不再共享各模块可以更安全地并行构建。这意味着你开-T 4甚至-T 8的时候踩到隐式依赖坑的概率会小很多。对于那部分真正需要引用其他模块产物的项目正确的做法是把依赖声明成正常的Maven依赖dependency而不是在脚本里偷偷引用路径。这个改造对老项目可能有点阵痛但改完之后整个构建会健康很多。另一个值得说的点是多版本JARMR-JAR的原生支持。以前想在同一个JAR里针对不同JDK版本提供不同实现需要额外配置maven-jar-plugin的相关参数版本稍微配错一点就容易出问题。Maven 4把这个能力内置到了默认构建流程里你按约定把src/main/java-17这种目录建好它会在打包时自动识别并处理。Java 8之后的版本尤其是Java 21普及的当下这个能力变得越来越实用。2.4 插件API现代化好消息和坏消息插件API的现代化是Maven 4“彻底重构”里最手术式的一刀。官方终于提供了一个稳定的、不依赖maven-core内部实现的插件API让插件作者可以基于org.apache.maven.api来开发。好处很明显未来插件和Maven主版本解耦Maven 5出来的时候老插件不会像以前那样死一片。但坏消息也在这那些基于老API写的插件在Maven 4里可能需要升级才能用。如果你的项目里有一些非常冷门的第三方插件或者自己公司内部开发的自定义插件那可能是迁移时最大的不确定因素。我见过不少团队卡在Maven 4迁移上不是Maven本身的问题而是某个很久没人维护的插件在Maven 4的插件注册阶段就报错。这种情况下的建议很直接先看看插件有没有新版本没有的话要么考虑用别的插件替代要么在项目里保留一个Maven 3的wrapper作为过渡。不要在这个节骨眼上强行自己改插件除非你真的有十二分的把握。2.5 Java版本门槛工具要新项目可以不新Maven 4对运行环境提出了更高的要求它自己必须跑在JDK 17及以上。很多人一听这个就慌了觉得“我项目还在用Java 8是不是不能升级Maven了”。这里要区分两个概念一个是Maven这个工具运行时的JVM版本一个是你的项目编译产物的Java版本。Maven 4要求的是前者你自己的项目代码依然可以用maven.compiler.release8来编译出Java 8的字节码。也就是说你完全可以在一台装了JDK 17的机器上用Maven 4去构建一个运行在JDK 8上的老项目。不过要注意的是Maven 4本身的某些新功能比如对Java新版本特性的感知会依赖到它运行时的JDK版本。如果你的系统里还全是JDK 8那升级Maven 4意味着你至少要在构建机上装一个新的JDK 17来跑Maven。这在很多保守的团队里会是一个审批层面的麻烦但技术上完全不是问题。我个人的建议是构建机的JDK完全可以比运行环境的JDK新这是很正常的操作用SDKMAN或者Docker镜像来管理构建环境都很方便。3. 从Maven 3升级到Maven 4我的实操记录3.1 升级前先做一次“无害体检”别一上来就换我在自己维护的开源项目上做了Maven 4的完整迁移测试又在公司的一个中型Spring Boot多模块项目上试了一遍。整个过程踩了不少坑但把流程理顺之后其实也就五步。第一步是体检而且是那种不改变任何环境配置的体检。先备份项目然后用mvn -v看一下当前Maven版本再用mvn help:effective-pom导出一份完整有效POM存档。接下来扫描一下项目里用到的所有插件记下版本号。最后确认一下所有依赖仓库是否支持HTTPS或者走的是内网镜像。做完这些你对项目的构建配置就有了一个完整的快照后面出了问题也能对照排查。这个步骤在Maven 3时代就很有用到了Maven 4这种大版本升级的节点更是必需。3.2 用Maven Wrapper固定版本比改全局环境靠谱切换Maven版本有两种常见方式。第一种是直接下载Maven 4的二进制包解压后改MAVEN_HOME和PATH环境变量。这种方式适合个人本机测试但团队协作时不推荐因为你没法保证每个同事都改了自己的环境变量。第二种方式是使用Maven Wrapper把项目固定到指定版本这也是我在实际工作中强烈推荐的方式。在项目根目录执行下面这条命令可以让项目使用Maven 4mvn -N wrapper:wrapper -Dmaven4.0.0执行完后项目里会生成mvnw和mvnw.cmd脚本以及对应的maven-wrapper.properties。之后团队所有人统一用./mvnw来构建版本就不会出现“我本地能构建你本地不行”这种经典问题。如果是在CI环境里也尽量让流水线使用项目的wrapper脚本而不是环境中预装的Maven这样能做到开发、测试、生产构建版本三端一致。3.3 插件版本兼容性是迁移中最容易翻车的地方我第一次在公司项目里切到Maven 4时遇到的第一个报错是maven-source-plugin的NoSuchMethodError。这个插件是用来打包源码JAR的并不是什么冷门插件但老版本内部用了Maven 3的类路径在Maven 4里直接崩了。当时我第一反应是“完了又要改一堆东西”结果查了一下发现升级到新版本就解决了。我自己验证过的、在Maven 4下工作正常的常见插件组合大致是这样供你参考插件建议版本备注maven-compiler-plugin3.13.0对Java 21支持更好Maven 4兼容maven-surefire-plugin3.2.5测试执行老版本可能挂maven-jar-plugin3.4.1MR-JAR支持更完善maven-source-plugin3.3.0老版本在Maven 4下易报错spring-boot-maven-plugin3.2.0公司项目用的Spring Boot 3这不是一份绝对权威的清单只是我实际验证过的一套组合。你在迁移自己的项目时最稳的做法是把所有插件都升到当前的最新版本然后逐个模块跑mvn verify。如果某个插件实在没有新版本那就把它排除掉或者找替代品尽量不要和老插件较劲。3.4 我迁移一个8模块项目的实测数据拿公司那个8模块的订单中台项目来说之前用Maven 3.9.6构建clean package -DskipTests全量构建大概是42秒。首次用Maven 4跑全量构建结果差不多也是40秒上下当时我还有点失望觉得“就这”但后来连续跑了几次发现第二次构建时间掉到了25秒左右第三次稳定在20秒上下。原因在于Maven 4的增量构建逻辑开始起作用了没有变动的模块会跳过大量重复操作。而我在Maven 3里用同样的命令连跑三次时间基本都稳定在40秒左右。这个对比让我意识到Maven 4的性能提升不是体现在“第一次全量构建”这种冷启动场景而是体现在日常开发的“改一个模块、重新构建整个项目”这种高频场景。以前改一个模块整个项目所有模块都要跟着重新跑一遍任务现在它会跳过没变化的模块这种体验上的提升是实实在在的。当然Maven 4的增量构建目前还有一些边界情况比如某些插件没有正确声明输入输出时可能不会被跳过但整体趋势是对的。4. Maven 4与Gradle对比现在到底该怎么选4.1 Maven 4拉平了多少差距每次Maven发新版本都绕不开和Gradle的对比。我在使用Gradle时确实感受到过它为什么受欢迎Groovy/Kotlin脚本灵活、增量构建快、多语言支持好、依赖缓存更强。但Gradle的缺点也同样明显学习曲线陡峭团队里想找一个能熟练维护Gradle脚本的人比找Maven的难得多而且脚本太过灵活之后很容易出现“每个模块的构建方式都不一样”的混乱局面这恰好和Maven“约定优于配置”的价值观相反。Maven 4出现之后我觉得两者在核心体验上的差距缩小了不少。Maven 4补上了多版本JAR、增量构建、构建隔离这些Gradle引以为傲的功能而Gradle的灵活性依然存在但也依然是双刃剑。给你一张表直观对比一下对比维度Maven 4Gradle配置方式XML声明式统一规范脚本编程式灵活度高构建速度全量构建接近增量构建已跟上增量构建和构建缓存仍是优势学习曲线低文档和生态成熟中高需要掌握DSL和脚本概念多模块支持构建隔离增强了稳定性天然支持成熟插件生态老牌插件多部分需要升级生态活跃但脚本维护成本高团队接管成本低几乎人人会高好用的前提是有高手维护4.2 从团队现实出发的选型建议而不是跟风如果问我Java后端项目现在选什么构建工具我的答案和几年前有些不一样。之前我会说“新项目能用Gradle就用Gradle体验好”但现在Maven 4发布后我会更倾向于推荐Maven理由很简单稳定和低门槛。对于一个业务团队来说构建工具消耗的心智越少越好它不应该成为团队的技术瓶颈。具体场景来看维护老项目的团队尽快迁移到Maven 4是性价比最高的选择兼容成本低而且能立刻吃到增量构建的红利。新启动的Java项目如果团队里没有特别熟悉Gradle的人直接用Maven 4完全没问题它的功能已经足够应对绝大多数场景。只有一种情况我会建议选Gradle项目需要非常复杂的自定义构建逻辑比如多语言混合、自定义依赖解析规则、复杂的发布流程或者团队本身就是构建工具爱好者的极客型团队。普通业务项目Maven 4的“确定感”比Gradle的“灵活感”更值钱。5. 常见问题与避坑实录Maven 4迁移不要慌5.1 我踩过的几个典型坑第一个坑就是前面说的老插件崩溃。报错往往长这样java.lang.NoSuchMethodError: org.apache.maven.plugin.descriptor.MojoDescriptor.getImplementation(Ljava/lang/String;)Ljava/lang/String;看到这种错误先别慌直接把对应的插件升到最新版本大概率解决。第二个坑是仓库地址被拒绝。Maven 3时代就开始默认屏蔽明文HTTP仓库了到了Maven 4这个策略更严格。有些老项目的内部仓库还是http://开头的构建时会直接报blocked mirror for repositories。解决方法是把仓库改成https://或者在内网搭建的仓库管理工具上配上HTTPS证书。如果只是个人开发测试可以在settings.xml里显式允许该仓库但团队项目不建议这么做。第三个坑是本地仓库残留的快照导致解析不一致。Maven 4如果遇到某些依赖一直解析出错误版本先清掉~/.m2/repository下对应路径的文件夹重新下载再试。这个操作在Maven 3时代就是万能药到Maven 4依然管用。第四个坑多模块项目里老脚本用相对路径引用其他模块的target目录在构建隔离下失效。这个只能老老实实去改项目结构把直接的路径引用替换成标准依赖。虽然麻烦但改完对项目健康度是加分项。5.2 问题排查速查表为了方便你对照我把迁移过程中常见的问题整理成了一张表报错或现象排查思路解决办法插件报NoSuchMethodError/ClassNotFound插件老API不兼容升级插件到最新版本仓库被blocked仓库使用HTTP而非HTTPS改仓库地址或配置本地镜像依赖解析出来的版本不对本地仓库有脏快照删除对应路径重新下载多模块并行构建失败模块间有隐式依赖显式声明依赖或者降级串行Maven本身启动报Java版本错误运行环境低于JDK 17给Maven单独配JDK 17自定义插件无法注册内部API被隔离迁移到新API或找替代插件我在实际项目里给出的建议其实很简单迁移Maven 4不是一次性的“替换版本”而是一个“渐进式改造”的过程。最好先在一个非核心模块上把整套流程跑通把插件清单、POM配置、仓库设置都调好然后再推广到整个项目组。最忌讳的是拿着旧项目一口气全局升级然后被一堆插件兼容性问题淹没最后又默默回滚到Maven 3这样反而会让团队对Maven 4失去信心。从Maven 2到Maven 4构建工具领域折腾了这么多年最后发现Java项目最需要的还是一个“确定的东西”确定的结构、确定的行为、确定的构建结果。Maven 4的这次重构本质上是把老房子里的旧管道全部换新但保留了原有的房屋格局。对Java开发者来说这是一个非常友好的信号——你不需要重新学一套构建工具只需要把自己项目里过时的部分慢慢修好就行。我自己是打算在新项目和大部分存量项目里逐步切到Maven 4至少在增量构建这一点上它已经值得我这样做。