从 2010 年 Maven 3 发布开始intellij idea 14，Maven 针对 Java 构建生态的整体支持途径，差不多未曾出现过具有颠覆性的改变。

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

相比之下，Maven 本身却显得有些“老态”。

促使 Maven 4 得以出现的原因，恰是为了去处理那些历经长久时间逐步积累起来的历史包袱 ，这是其存在的意义所在 。

虽说Maven 4依旧没有公布正式GA发布时间，不过当下已然迭代到了第五个发布候选版本，也就是RC5，就项目成熟程度以及变更稳定性而言，距离正式发表已然颇为接近了。

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

POM 模型升级：从 4.0.0 到 4.1.0

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

ini

4.1.0

也就是说：

能用 Maven 4，即便不升级 POM，可惟有升级以后，才能够真正地“尝到甜头” 。

构建项目对象模型，项目对象模型分离，终于将“项目对象模型污染”这一问题给解决掉了。

这是 Maven 4 最重要、也是最颠覆性 的变化之一。

在 Maven 3 中，发布到仓库的 POM 同时包含：

依赖使用者会被迫解析大量 “与我无关” 的信息。

Maven 4 的解决方法是 POM 扁平化（）。

Maven 4 正式区分：

POM 具备以下特征：

开启方式：

ini

mvn clean -..pom.=true

在 Maven 3 的那个时期，是需要另外额外的 Maven 的，而在 Maven 4 里面，它已然变成了原生的能力 。

这一步，直接让依赖解析更快、更干净、更可预测。

新 Type：显式控制 / path

在 Maven 3 中：

这种“隐式规则”在 Java 模块化时代并不够清晰。

Maven 4 新增类型：

lua

-jar -jar

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

Maven 4 还新增了专门的注解处理器类型：

以 为例：

xml

org. ${.} - org. ${.}

Maven 4清晰明确地区分开了API与某些内容，其构建语义变得更加清晰起来了，并且这些清晰的构建语义更有利于工具链进行优化了。

改名为 ：为 Java 9 “让路”

Java 9 引入模块系统后：

长期让新手和工具“集体懵逼”。

Maven 4 的选择是：

xml

-a -b

同时还支持：

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

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

Maven 3有着线性的生命周期intellij idea 14，就算存在多模块的情况，想要高效并行也是极为困难的。

Maven 4 引入 Tree-based ：

开启方式：

css

mvn -b

配置能力显著增强的“小变化”1. 条件表达式

scss

将路径中的点替换为当前目录，然后匹配源目录下所有子目录中以xsd为后缀的文件，并且，用户名字符串的长度大于5 ，并一起组成一个逻辑表达式 。

不单单止于是os.name、jdk这般的基础判断了，而是成为了真正的表达式系统的样子，是如此这般的情况 。

2. 统一的 模型

Maven 3：

xml

... ...

Maven 4：

xml

主要我的——目录/foo，测试我的——目录/bar。

更适合：

Maven 4 还提供了官方升级工具：

bash

针对“mvnup check”来讲，它仅会生成报告，而“mvnup apply”呢，则是会自动进行修改 。

它会分析：

并给出 可执行的升级建议。

如有侵权请联系删除！