自 2008 年 Maven 2 发布 以来Maven 对 Java 形成环境的整体支持方式，几乎没有发生颠覆性的变化。

只是在这 15 年 里Java 世界已经天翻地覆：

• 模块化成为标配
• 并行建立成为刚需
• 云原生与容器化越来越多人使用
• JDK 以一年两个大版本的节奏持续快速演进

使用者痛点：

• 老旧的 POM 模型让项目迁移成本高
• 依赖解析时被大量 “与我无关” 的插件配置和父 POM 信息污染
• 模块方法与类方法混用导致运行时错误难排查
• 多模块项目只能线性执行。建立时间难以接受
• 配置碎片化、缺少统一的源码模型，导致 IDE 与 CI 环境不一致

Maven 本身却显得有些 “老态”。Maven 的出现正是为了解决这些长期积累的历史包袱。虽然 Maven 4 尚未公布正式 GA 日期。但已经迭代到 第五个发布候选版本从项目成熟度和变更稳定性来看，距离发布已相当接近。其实，

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

POM 模型升级：从 4.0 到 5.0

Maven 将 POM 的模型版本升级为 5.0

5.0

• 向后兼容：Maven 仍然可以建立基于旧版的 POM。
• 新能力只对 5.x 生效：只有升级后才能使用全新特性。
• modelVersion 理论上可以省略，Maven 会从 schema 推导。

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

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

Maven 最关键、也是最颠覆性的变化之一。

在传统 Maven 中。发布到仓库的 POM 同时包含：

• 插件配置
• 建立细节
• 父 POM 引用
• 各种属性和 profile 信息

User Pain Point：依赖使用者在解析 POM 时必须处理大量 “与我无关” 的信息，导致解析慢、冲突多。

Maven 的方法是 **POM 扁平化**——原生支持 Build POM 与 Consumer POM 的分离。

Consumer POM 特征：

• 不包含插件配置或父 POM 引用。
• 不包含未使用的依赖。
属性已被解析为具体值，不再需要额外变量解析。

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

Maven 时代需要额外的 Flatten Maven Plugin，而在 Maven 4 中这已经是 **原生能力**。一次性让依赖解析更快、更干净、更可预测。

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

Maven 长期采用隐式规则：

• 含module‑info.class → module‑path

Maven 4 新增两种明确的 artifact 类型：

• classpath‑jar — 明确声明仅放入传统 classpath
• module‑jar — 明确声明应放入 module‑path

 classpath‑jar
module‑jar

者现在可以 **显式声明依赖放在哪里**，避免因隐式推断产生的错误。

Maven 同时引入了专门针对注解处理器的新类型：

• processor
• classpath‑processor
• modular‑processor

以 Lombok 为例：

org.projectlombok
lombok
${lombok.version}
classpath‑processor


org.projectlombok
lombok
${lombok.version}
provided>

Maven 明确区分了 API classpath 与 processor classpath。建立语义更清晰，也更利于工具链调整。

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

Java 引入模块程序后“Maven Modules” 与 “Java Modules” 两套概念长期让新人和工具“集体懵逼”。按理说，

Maven 的选择是将旧概念 **modules → subprojects** 并标记 **modules 为 deprecated**。

project-a
project-b


提供了一系列便利特性：


Parent 推断 ：空  自动识别最近的父项目。

子项目自动发现 ：无需显式列出子项目，Maven 会扫描目录结构。

统一建立时间戳 ：所有子项目共享同一时间戳，提高 reproducibility。

安全发布 ：任意子项目失败会导致整个聚合发布被阻止，防止半成品流出仓库。


这是一场语义层面 + 工程实践层面的双重升级，让大型单体迁移到真正的多模块程序变得轻松。

至于树形生命周期。并行建立终于 “名正言顺” 

Maven 的传统生命周期是 **线性的**——即使是多模块，也只能顺序执行，浪费大量 CPU 主要。

Maven 4 引入 **Tree‑based Lifecycle**：每个子项目拥有独立的生命周期节点。只要其依赖准备就绪即可立即启动对应阶段，实现真正意义上的并行建立。