Maven 4 要来了:15 年后,Java 构建工具迎来"彻底重构"

0 阅读5分钟

大家好,我是Java1234_小锋老师。

image.png

一、为什么 Maven 4 等了这么久?

如果你用 Java 做项目,Maven 大概率不陌生。

2004 年 Maven 2 发布,2010 年 Maven 3 上线——之后十多年,社区一直在 3.x 小版本上迭代。不是团队偷懒,而是 POM 文件背负了太多东西:既要描述"怎么构建",又要告诉下游"怎么依赖我"。

一旦改 POM 格式,Maven Central、IDE、Gradle 互操作、各类插件都要跟着动。于是 POM 4.0.0 的语法几乎被"冻住"了,很多 2005 年就提过的改进(比如自动推断父 POM 版本)一直拖到现在。

Maven 4 的思路很直白:把"构建用的 POM"和"给别人用的 POM"分开。构建时可以大胆进化,发布到仓库时仍保持兼容。这才是标题里"彻底重构"的真正含义——不是换皮,而是把底层架构理顺了。


二、Maven 4 现在走到哪一步了?

截至 2026 年 7 月,Maven 4 已发布多个 RC(Release Candidate)版本,最新为 4.0.0-rc-5(2025-11-13)。官方仍标注为测试用途,生产环境建议等 GA 正式版。

几个硬性变化需要提前知道:

项目Maven 3.xMaven 4
运行 Maven 本身Java 8+Java 17+
编译项目代码自行配置仍可编译 Java 8/11/17 等
POM 模型4.0.0构建可用 4.1.0
依赖解析Resolver 1.xResolver 2.0

注意:Java 17 只是运行 Maven 的要求,不代表你的项目必须升到 Java 17。老项目照样可以用 Toolchains 指定编译 JDK。

image.png


三、核心变化:Build POM 与 Consumer POM 分离

这是 Maven 4 最重要的架构调整。

  • Build POM:存在 Git 仓库里,包含插件配置、属性、父 POM 引用等完整信息。
  • Consumer POM:发布到 Maven Central 的精简版,只保留下游真正需要的依赖信息。

构建完成后,Maven 4 会自动从 Build POM 生成 Consumer POM。Consumer POM 会去掉 parent 引用(继承内容已内联)、去掉插件配置、只保留实际用到的依赖。

image.png

构建与发布流程

image.png

如何开启 Consumer POM 发布?

在 rc-5 中,Consumer POM 扁平化默认关闭,需要显式开启:

<!-- .mvn/maven-user.properties -->
maven.consumer.pom.flatten=true

或在命令行传递:

mvn deploy -Dmaven.consumer.pom.flatten=true

四、POM 4.1.0:少写重复配置

升级到 POM 模型 4.1.0 后,很多"复制粘贴式"的配置可以删掉了。Maven 3 的 4.0.0 POM 仍然能正常构建,不升级也不影响。

1. 父 POM 版本自动推断

2005 年的老需求,Maven 4 终于内置了。子模块不必再写 <version>

<project xmlns="http://maven.apache.org/POM/4.1.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.1.0
         https://maven.apache.org/xsd/maven-4.1.0.xsd">
​
  <!-- 省略 version,Maven 自动从父目录推断 -->
  <parent>
    <groupId>com.example</groupId>
    <artifactId>my-app-parent</artifactId>
  </parent>
​
  <artifactId>my-service</artifactId>
​
  <dependencies>
    <!-- 同仓库子模块依赖也可省略 version -->
    <dependency>
      <groupId>com.example</groupId>
      <artifactId>my-common</artifactId>
    </dependency>
  </dependencies>
</project>

2. 子模块自动发现

父 POM 使用 pom 打包,且没有手动写 <subprojects> 时,Maven 4 会自动扫描子目录里的 pom.xml

<project xmlns="http://maven.apache.org/POM/4.1.0">
  <modelVersion>4.1.0</modelVersion>
  <groupId>com.example</groupId>
  <artifactId>my-app-parent</artifactId>
  <version>1.0.0-SNAPSHOT</version>
  <packaging>pom</packaging>
​
  <!-- 不写 subprojects,子目录有 pom.xml 就会自动加入构建 -->
</project>

3. CI 友好版本号,不再需要 Flatten 插件

Maven 3 时代常用 ${revision} 配合 flatten-maven-plugin。Maven 4 内置完整支持:

<groupId>com.example</groupId>
<artifactId>my-app</artifactId>
<version>${revision}</version>
# 在 CI 流水线中指定版本
mvn verify -Drevision=1.2.0

或在 .mvn/maven.config 中固定:

-Drevision=1.0.0-SNAPSHOT

4. 新的 BOM 打包类型

BOM(Bill of Materials)有了专属 packaging 类型,和 parent POM 职责分得更清楚:

<project xmlns="http://maven.apache.org/POM/4.1.0">
  <modelVersion>4.1.0</modelVersion>
  <groupId>com.example</groupId>
  <artifactId>my-app-bom</artifactId>
  <version>1.0.0</version>
  <packaging>bom</packaging>

  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-dependencies</artifactId>
        <version>3.4.0</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
    </dependencies>
  </dependencyManagement>
</project>

5. 多源码目录,告别 Build Helper 插件

<build>
  <sources>
    <source>
      <scope>main</scope>
      <directory>src/main/java</directory>
    </source>
    <source>
      <scope>main</scope>
      <directory>src/main/kotlin</directory>
    </source>
    <source>
      <scope>test</scope>
      <directory>src/test/java</directory>
    </source>
  </sources>
</build>

五、新工具与日常体验升级

Maven Upgrade Tool(mvnup)

官方提供的迁移助手,先检查、再自动修复:

# 检查项目与 Maven 4 的兼容问题
mvnup check

# 自动应用推荐的 POM 修复
mvnup apply

Maven Shell(mvnsh)

类似 REPL 的交互式 Shell,改完代码不用反复敲完整命令:

mvnsh
# 进入交互模式后
mvn> compile
mvn> test -pl my-service
mvn> exit

构建失败后一键续跑

多模块项目构建失败后,Maven 4 的 -r--resume)更聪明——会自动从失败模块续跑,并跳过已成功构建的模块:

# 首次全量构建
mvn verify

# 修复代码后,从失败处继续
mvn verify -r

迁移决策流程

image.png


六、从 Maven 3 迁移,可以怎么做?

不必一步到位。比较稳妥的路径:

  1. 本地先试:装 Maven 4 RC + JDK 17,跑 mvnup check
  2. 升级插件:enforcer、shade、remote-resources 等插件升到最新版。
  3. 固定插件版本:Maven 4 的 Super POM 默认插件版本有变化,建议在 POM 里显式写死版本,避免"没改代码构建行为却变了"。
  4. CI 并行验证:保留 Maven 3 流水线,新增一条 Maven 4 试验线。
  5. 等 GA 再全面切换:RC 阶段适合尝鲜和反馈,生产环境建议等正式版。

一个最小验证示例:

# 下载并解压 Maven 4
curl -L -O https://archive.apache.org/dist/maven/maven-4/4.0.0-rc-5/binaries/apache-maven-4.0.0-rc-5-bin.tar.gz
tar -xzf apache-maven-4.0.0-rc-5-bin.tar.gz

# 指定 Maven 4 运行(不影响系统默认 Maven 3)
/path/to/apache-maven-4.0.0-rc-5/bin/mvn -version

# 在项目目录检查兼容性
/path/to/apache-maven-4.0.0-rc-5/bin/mvnup check

七、写在最后

Maven 4 不是简单地把版本号从 3 改成 4。

它用 Build POM / Consumer POM 分离 解开了 POM 格式冻结的死结,用 POM 4.1.0 把十多年来社区的呼声落到了代码里,还带来了 mvnup、mvnsh、Resolver 2.0 等实打实的体验提升。

如果你现在项目跑在 Maven 3 上很稳,不必焦虑——Maven 3 还会维护一段时间。但如果你正在维护大型多模块项目、受够了重复的版本号维护、或者在 CI 里被 flatten 插件折腾过,现在正是关注 Maven 4 的好时候。

GA 正式版应该不远了。在那之前,不妨拿一个非核心项目跑通 mvnup check,亲身感受一下这次"15 年后的彻底重构"到底改了什么。