本文不介绍IDEA 2022.1版本的新特点只关注作者对版本升级最感兴趣的部分：IDEA依赖分析器。顺便简单介绍一下。Maven，以及作者卸载的Maven Helper插件。

Maven是Apache开源组织奉献的开源项目。Maven这个词可以翻译成知识积累、专家或专家。

Maven本质是一个项目管理工具，将项目开发和管理过程抽象成项目对象模型（POM）。开发人员可以批量完成项目建设、报告和文件生成，只需做一些简单的配置。它是跨平台的，这意味着无论是在Windows上，还是在Linux或者Mac同样的命令可以用在上面。

说了这么多，本文只着眼于Maven的一项功能：依赖管理。这是开发者和Maven处理最多的功能也是Maven核心能力之一。

早期的Java开发人员，依赖需要手动管理，是个大问题。这种事情不仅费时费力，而且容易出错。Ant这个问题已经缓解了，但直到Maven只有这样，才能真正彻底解决依赖管理的问题，让开发者全身心投入到开发中去。

要理解好Maven依赖管理，首先要了解相关概念。说明:本文不是Maven文章，只对Maven依靠管理的概念进行简单的科普。

依赖的scope决定其生效范围决定了其生效范围：

• build生效
• test生效
• runtime生效

scope各种取值：

• compile : scope缺省值。三个范围生效，参与包装。例如：spring-core
• provided : build生效，test生效，runtime不生效，不参与包装。例如：servlet-api
• runtime : build不生效、test生效，runtime生效，参与包装。例如：mysql-connector-java（JDBC驱动）
• system : build生效，test生效，runtime不生效，不参与包装。不是从maven引入仓库，但在当地目录下jar，不推荐使用
• test： build不生效，test生效，runtime不生效，不参与包装。例如：JUnit、Mockito
• import ：仅仅在dependencyManagement内部只有这个值，对范围无效。用于引入外部依赖和依赖管理

知识点：runtime不生效的，不参与包装，不参与包装不参与传输，因为在包装阶段，使用运行classpath。

<dependency>     <groupId>org.projectlombok</groupId>     <artifactId>lombok</artifactId>     <scope>provided</scope>
</dependency>

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-devtools</artifactId>
    <optional>true</optional>
</dependency>

从结果来看：二者是一样的。都不会被打入包中，依赖不会传递给上层。所以它哥俩的区别在于使用场景上。

• optional：表示该依赖是可选的，它的侧重点是强调这个依赖是可选的，不会被打入jar包内，也不会传递。注意：即使不传递、不打入jar包的内，运行时也不能报错
  • optional更强调一种规范使用，表示可选，但即使没有该依赖也不影响程序运行，所以一般是需要程序进行一些额外的判断逻辑来保证程序的健壮性。
• provided：表示这个依赖是必须的，但是呢这个依赖通常在运行期不需要或者已经被提供了，比如lombok运行期不需要，servlet-api运行期已提供，所以都适合用provided而不适合用optional

最后，分享一个比喻，将二者的区别道出来，我觉得特别好，分享给你：

• optional：吃面时候，酱油、辣椒等就是可选的（强调可选性），加不加都不会影响面的正常食用（强调结果正确性，运行期不会报错）
• provided：吃面时候，筷子、碗是必须的（强调必须性），不过这些一般是店家给顾客备好，不需要顾客自带（强调结果正确性，运行期只是不需要有而已）

如图，Maven的依赖传递机制，大大地减少了人工维护间接依赖的复杂度。

至于哪些依赖可以向下继续传递，上个part已经有结论了：参与打包的就可以传递依赖，runtime生效的scope才会参与打包，也就是只有compile和runtime这两个scope能够传递依赖。

Maven管理传递依赖时，绝大部分时候我们无需关心依赖是哪儿来的。只有当依赖出问题时（比如希望是xx版本，但实际进来的是yy版本），才需要搞清楚此依赖是哪条路径进来的，为什么是这条路径。所以，当一个间接依赖来自多个路径时，了解Maven的依赖仲裁策略非常重要，是解决此问题的关键。

Maven依赖仲裁其实也比较简单，总结一下就两个原则：

1. 路径最短者优先
2. 先声明者优先

优先使用第1原则，当第1原则无法解决时，则通过第2原则决定。举个简单的例子辅助理解一下：

项目A的依赖如下，问：A最终依赖Z的版本号是多少？

A -> B -> C -> D -> Z(1.0)  // 路径长度4
A -> X -> Y -> Z(2.0)   // 路径长度3 

答：2.0。原因：Z(1.0)的依赖路径长度为4，而Z(2.0)路径长度是3，根据路径最短者优先原则，最终Z的版本号为2.0。

那么，问题来了。在实际生产项目中，这种间接依赖的场景会非常非常多，怎样高效的定位问题所在呢？maven提供了相关依赖分析命令：

• 查看依赖列表：mvn dependency:list
• 查看依赖以树状展示：mvn dependency:list
• 依赖分析：mvn dependency:analyze

虽然命令有了，但分析起来还是不够直观，那么破？

在集成开发环境时代，这种棘手问题肯定早已被解决，它就是：Maven Helper。

它是IDEA的一个插件，可以通过 UI 界面的方式来查 Maven项目的依赖关系，很是直观。由于Java项目大都使用Maven进行管理，所以Maven Helper几乎可以说是必装插件。 在IDEA 2022.1发布之前，笔者一直使用它。看插件的评分，是我见过的评分最高的插件，非常优秀。

安装好插件后，打开pom.xml文件，可以看到左下角靠右边多了个Dependency Analyzer： 点击此tab进入Maven Helper的功能区： 如上图所示，commons-lang和jackson-core存在冲突，这里以jackson-core为例解释冲突的原因以及为何最终仲裁为2.9.9版本。

原因：此依赖存在多个路径，且版本号还不一样：

1. pom里显示引入（直接依赖），版本号为2.9.9
2. 通过jackson-databind间接引入，版本号为2.11.3（jackson-databind的版本号为2.9.9） 结果解释：直接依赖的路径长度是1，通过jackson-databind间接依赖的路径是2，按照路径最短者优先原则最终仲裁出来的版本号为2.9.9。

有时候，若就想要2.11.3这个版本生效，或者想解决所有conflicts避免隐患怎么办？这个时候就可以借助exclude来做，使用Maven Helper提供的图形化界面操作非常的方便，在想要排除的地方右键： 点击Exclude后的效果为： 自动帮你把exclusion部分加上去了。然后刷新刚才的视窗，发现此冲突完美解决： 依赖分析和解决冲突是Maven Helper最常用的功能，甚至没有之一。

这个用处，其实没那么的大。毕竟IDEA提供的Maven视窗已足够好用，就算偶尔手敲两个命令也不算麻烦。 还有其它功能比如展示依赖关系图、在当前位置快速启动命令行等，我觉得实用性都不算高，就不做过多介绍了。

那么问题来了，笔者作为Maven Helper的忠实用户，它也确实很好用，为何还将其卸载呢？

一切只因IDEA 2022.1发布了。

JetBrain在2022年4月26日，正式发布了IntelliJ IDEA 2022.1。本次属于大版本升级，对使用者来讲最大的改变就是引入了 Dependency Analyzer，依赖分析器。

Dependency Analyzer，用于以UI方式管理依赖项和解决冲突。我去，咋一看这就是冲着Maven Helper来的呀，几乎完全重叠有木有。

在IDEA的maven视窗里点击依赖分析按钮，进入依赖分析窗口，如下图所示： 此窗口顶部有多个选项区域，逐个解释：

选择maven模块：对于多模块的项目，这里可以选择按模块处理依赖关系 选择Scope：默认选择所有 是否显示GroupId：多数情况下GroupId都不用显示，所以默认情况下此选项也是没有被选中的 是否只显示有冲突的依赖：

下面重点看看IDEA在冲突上的显示和处理能力，和Maven Helper还是有点不一样的： 请注意理解这个视窗，它和Maven Helper的Conflicts是有明显区别的。IDEA的是：

• 坐标表示已经解决的依赖们。换句话讲：列出来的依赖是有问题的（和实际生效的版本冲突的、没有存在意义的），这样开发者可以非常有针对性的解决左边这些依赖们
• 右边窗口显示的是左边光标选中的依赖的一个使用情况（是谁把你带进来了，依赖路径有多长）

注意对比下面窗口列表和👆🏻的不同，这里表示最终生效的版本号： 笔者个人认为，这种显示方式是优于Maven Helper的，很是直观。真可谓JetBrain出品，必属精品。

奈何，有个小小缺陷：当我想要通过exclusion方式去解决冲突的jar时，它并不能“一键”帮我完成，而只能导航到问题处自己手动解决： 你觉得IDEA后续会把“该功能”加上来吗？

使用IDEA自带的依赖分析器，打开的pom.xml文件时并不会和Maven Helper一样多出一个tab，而是保持原样： 最后，值得一提的是：IDEA的Dependency Analyzer功能不仅适用于Maven，还适用于Gradle。 最后，值得一提的是：IDEA的Dependency Analyzer功能不仅适用于Maven，还适用于Gradle。 最后，值得一提的是：IDEA的Dependency Analyzer功能不仅适用于Maven，还适用于Gradle。

新版IDEA提供的Dependency Analyzer依赖分析功能，笔者认为不输Maven Helper。重点是前者是原生自带的（且还支持Gradle），后者还得额外安装插件，孰优孰劣高下立判。所以，我头也不回的卸载了Maven Helper，相忘于江湖。

赶紧升级到最新的IDEA 2022.1版本吧，一起体验它的依赖分析工具，以及something else new~

• 【方向盘】工具提效：Sublime Text 4的常用快捷键合集
• 【方向盘】使用IDEA的60+个快捷键分享给你，权为了提效（Git&Other&完结篇）
• 【方向盘】使用IDEA的60+个快捷键分享给你，权为了提效（Live Template&Postfix Completion篇）
• 【方向盘】使用IDEA的60+个快捷键分享给你，权为了提效（重构篇）
• 【方向盘】使用IDEA的60+个快捷键分享给你，权为了提效（代码补全篇）
• 【方向盘】使用IDEA的60+个快捷键分享给你，权为了提效（运行/调试篇）
• 【方向盘】使用IDEA的60+个快捷键分享给你，权为了提效（视窗、选择篇）
• 【方向盘】使用IDEA的60+个快捷键分享给你，权为了提效（导航篇）
• 【方向盘】使用IDEA的60+个快捷键分享给你，权为了提效（操作系统、终端篇）

• 【方向盘】蚂蚁金服上市了，我不想努力了
• 【方向盘】每人送1G超小容量，“BAT网盘”免费助你做减法
• 【方向盘】因“双减”失业，厉经9面，终获美团外卖L8的Offer