【方向盘】升级到IDEA 2022.1版本后，我把Maven Helper卸载了

2022-09-16 14:16:56 浏览数 (3)

​

本文已被https://yourbatman.cn收录；女娲Knife-Initializr工程可公开访问啦；程序员专用网盘https://wangpan.yourbatman.cn；技术专栏源代码大本营：https://github.com/yourbatman/tech-column-learning；

你好，这里是Java方向盘，我是方向盘(YourBatman)，坐稳扶好，开始发车。

Title

Link

所属专栏

【方向盘】-IntelliJ IDEA

源代码

https://github.com/yourbatman/FXP-java-ee

程序员专用网盘公益上线啦，注册送1G超小容量，帮你实践做减法

https://wangpan.yourbatman.cn

Java开发软件包(Mac)

https://wangpan.yourbatman.cn/s/rEH0 提取码：javakit

女娲工程

http://152.136.106.14:8761

版本约定

IntelliJ IDEA 2022.1.1

之前有追写过多篇IDEA新特性的文章，每篇都能被CSDN官方首页推荐/公众号转载：

​

  • IntelliJ IDEA 2020.3正式发布，年度最后一个版本很讲武德
  • IntelliJ IDEA 2020.2正式发布，诸多亮点总有几款能助你提效
  • IntelliJ IDEA 2020.1正式发布，你要的Almost都在这！
  • IntelliJ IDEA 2019.3正式发布，给我们带来哪些新特性？
  • IDEA命令行缩短器助你解决此问题：Command line is too long. Shorten command line

每次IDEA发布新版本，我都是第一时间升级。现在为啥不追着写篇文章介绍了呢？主要有两个原因：

  1. 明显感觉从2020年后的升级，新特性就比较小了。毕竟IDEA已非常成熟
  2. 疲了，也追不动了

所以每次，自己默默升上去就好：

Tips：每次升级IDEA后都能看到全新的启动图，还蛮有新鲜感的。

✍正文

本文并不是介绍IDEA 2022.1版本的新特性，而是只着眼于笔者对此次版本升级“最感兴趣”的部分：IDEA依赖分析器。顺道简单介绍下Maven，以及笔者卸载掉的Maven Helper插件。

Maven

Maven是Apache开源组织奉献的一个开源项目。Maven这个单词可以翻译为“知识的积累”，也可以翻译为“专家”或“内行”。

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

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

✌Maven依赖管理

早期的Java开发者，依赖需要手动管理，是个大问题。你造的，这种事不仅费时费力，而且还容易出错。Ant缓解了这个问题，但还是直到Maven的出现，才真正彻底解决了依赖管理这个问题，让开发者可以全心投入到开发中去。

要理解好Maven的依赖管理，得先了解相关概念。说明：本文并非Maven文章，只对Maven依赖管理方面的概念做简单科普。

依赖的Scope

依赖的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。

小插曲：provided和optional的区别
代码语言：javascript复制
<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的版本号是多少？

代码语言：javascript复制
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。

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
  1. 通过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最常用的功能，甚至没有之一。

✌功能：快速执行maven命令

这个用处，其实没那么的大。毕竟IDEA提供的Maven视窗已足够好用，就算偶尔手敲两个命令也不算麻烦。

还有其它功能比如展示依赖关系图、在当前位置快速启动命令行等，我觉得实用性都不算高，就不做过多介绍了。

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

一切只因IDEA 2022.1发布了。

IDEA 2022.1

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

✌功能：Dependency Analyzer

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

在IDEA的maven视窗里点击依赖分析按钮，进入依赖分析窗口，如下图所示：

此窗口顶部有多个选项区域，逐个解释：

选择maven模块：对于多模块的项目，这里可以选择按模块处理依赖关系

选择Scope：默认选择所有

是否显示GroupId：多数情况下GroupId都不用显示，所以默认情况下此选项也是没有被选中的

是否只显示有冲突的依赖：

下面重点看看IDEA在冲突上的显示和处理能力，和Maven Helper还是有点不一样的：

请注意理解这个视窗，它和Maven Helper的Conflicts是有明显区别的。IDEA的是：

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

注意对比下面窗口列表和

maven spring https 网络安全 analyzer

0 人点赞