Maven 4 新特性解析：POM分离、并行构建与Java模块化升级指南

自 2010 年 Maven 3 发布以来，Maven 对 Java 构建生态的整体支持方式，几乎没有发生过颠覆性的变化。

然而在这 15 年里，Java 世界早已天翻地覆：

• 模块化成为标配
• 并行构建成为刚需
• 云原生与容器化成为主流
• JDK 以一年两个大版本的节奏持续快速演进

相比之下，Maven 本身却显得有些“老态”。Maven 4 的出现，正是为了解决这些长期积累的历史包袱。

虽然 Maven 4 仍未公布正式 GA 发布日期，但目前已经迭代到 第五个发布候选版本（RC5），从项目成熟度和变更稳定性来看，距离正式发布已相当接近。

现在正是提前了解、评估和准备升级的合适时机。

POM 模型升级：从 4.0.0 到 4.1.0

Maven 4 将 POM 的模型版本升级为 4.1.0：

<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
                     http://maven.apache.org/xsd/maven-4.1.0.xsd">
<modelVersion>4.1.0</modelVersion>
</project>

• 向后兼容：Maven 4 仍然可以构建 4.0.0 的 POM
• 新能力只对 4.1.0 生效：只有在 POM 中声明 modelVersion 为 4.1.0 时，才能使用 Maven 4 的新特性。
• 自动推导：理论上可以省略 modelVersion，Maven 会根据 XML Schema 来推导。

也就是说：

不升级 POM 也能用 Maven 4，但升级后才能真正“吃到红利”。

Build POM / Consumer POM 分离：终于解决“POM污染”

这是 Maven 4 最重要、也是最颠覆性的变化之一。在 Maven 3 中，发布到仓库的 POM 同时包含：

• 插件配置
• 构建细节
• 父 POM 引用
• 各种属性

这导致依赖使用者会被迫解析大量“与我无关”的信息，严重影响依赖解析效率和构建的确定性。

Maven 4 的解决方法是 POM 扁平化（Flattening），它正式区分了两种POM：

类型	用途
Build POM	项目自身构建时使用
Consumer POM	提供给依赖方使用

Consumer POM 具备以下特征：

• 不包含插件配置
• 不包含父 POM 引用
• 不包含未使用的依赖声明
• 只保留真实的传递性依赖
• 所有属性已被解析为具体值

开启方式：

mvn clean install -Dmaven.consumer.pom.flatten=true

Maven 3 时代需要额外的 Flatten Maven Plugin 插件，而在 Maven 4 中，这已成为原生能力。

这一步直接让依赖解析更快、更干净、更可预测，为构建工具的演进奠定了更好的基础，尤其是在复杂的企业级 后端架构 中，这种改进的价值会更加明显。

新 Artifact Type：显式控制 classpath / module path

在 Maven 3 中，JAR 包被放置到 classpath 还是 module path 是由工具隐式推断的：

• 普通 JAR → classpath
• 包含 module-info.class 的模块化 JAR → module path（自动推断）

这种“隐式规则”在 Java 模块化时代并不够清晰。Maven 4 新增了显式的依赖类型：

<type>classpath-jar</type>
<type>module-jar</type>

开发者终于可以显式声明依赖应该放在哪里。

同时，Maven 4 还新增了专门的注解处理器类型，以便更清晰地管理编译时依赖：

• processor
• classpath-processor
• modular-processor

以 Lombok 为例的配置：

<dependencies>
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>${lombok.version}</version>
<type>classpath-processor</type>
</dependency>

<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>${lombok.version}</version>
<scope>provided</scope>
</dependency>
</dependencies>

Maven 4 明确区分了 API classpath 与 processor classpath，构建语义更清晰，也更利于工具链进行优化。

Modules 改名为 Subprojects：为 Java 9 “让路”

Java 9 引入模块系统后，两个概念长期并存，让开发者和工具都容易混淆：

• Maven Modules（多模块项目中的子模块）
• Java Modules（Java 9 引入的模块化单元）

Maven 4 的选择是进行语义上的明确区分：

• 将 modules 更名为 subprojects
• 原有的 modules 元素标记为已弃用（deprecated）

配置示例：

<subprojects>
<subproject>project-a</subproject>
<subproject>project-b</subproject>
</subprojects>

此外，Maven 4 还引入了多项工程实践层面的改进：

• Parent 推断：空的 <parent /> 元素可以自动识别父项目。
• 子项目自动发现：无需在 POM 中显式声明所有子项目。
• 统一构建时间戳：确保多模块构建输出的一致性。
• 安全发布：如果任何一个子项目构建失败，整个项目的发布操作都会被阻止。

这是一次语义层面与工程实践层面的双重升级。

树形生命周期：并行构建终于“名正言顺”

Maven 3 的生命周期是线性的，即使在多模块项目中，也很难实现高效的并行构建。Maven 4 引入 Tree-based Lifecycle（基于树的生命周期）来解决这个问题：

• 每个子项目可以独立推进其生命周期阶段。
• 只要某个子项目的依赖就绪，它就可以立即开始构建。
• 这对于大型多模块项目来说，构建速度将得到显著提升。

开启树形生命周期并行构建的方式：

mvn -b concurrent verify

配置能力显著增强的“小变化”

1. 条件表达式 Profile

Maven 4 增强了 Profile 的条件判断能力，不再局限于 os.name、JDK 版本等基础属性，而是提供了一个真正的表达式系统。

<condition>
  exists('${project.basedir}/src/**/*.xsd')
  && length(${user.name}) > 5
</condition>

2. 统一的 Sources 模型

Maven 3 中使用分散的元素来定义源码目录：

<sourceDirectory>...</sourceDirectory>
<testSourceDirectory>...</testSourceDirectory>

Maven 4 则引入了统一的 <sources> 模型，使其配置更加灵活和清晰：

<sources>
<source>
<scope>main</scope>
<directory>my-custom-dir/foo</directory>
</source>
<source>
<scope>test</scope>
<directory>my-custom-dir/bar</directory>
</source>
</sources>

这种新模型更适合以下场景：

• 包含多个源码目录的项目。
• 需要为不同版本或变体维护不同源码的项目。
• 模块化项目。
• 希望减少对特定插件配置依赖的场景。

官方升级工具

为了方便开发者从 Maven 3 迁移到 Maven 4，官方提供了升级工具 mvnup：

mvnup check    # 只生成分析报告，不进行修改
mvnup apply    # 根据分析结果自动修改项目配置

该工具会分析你的项目结构、POM 文件以及插件使用情况，并给出可执行的升级建议，帮助开发者平滑过渡。

Maven 4 的这次重大更新，标志着这一经典 构建工具 为迎接现代 Java 开发范式做好了准备。对于正在使用 Maven 的团队来说，现在开始评估和了解这些变化，无疑是一个明智的选择。