Maven项目中的依赖出现版本冲突，最终发现是对Dependency Scope理解有误

Posted 2023-04-11 叫我二蛋

再来个文章目录

文章目录

• 背景
• 疑问
• 排查过程
• 问题存在的原因
• 总结
• 示例依赖版本说明

本文记录一下遇到maven依赖版本冲突后的排查过程说明以及问题原因说明
下面还有投票，帮忙投个票👍

背景

最近加入了 Apache Dubbo 开源社区，成为了一名Dubbo Contributor。在熟悉Dubbo中的各个RPC协议时根据官网提供的示例搭建了一个示例。在熟悉过后想看下谷歌提供的grpc协议在使用上与dubbo提供的grpc协议的区别，所以打算根据grpc github 基础教程跑一个示例，在引入相关依赖以及代码后进行编译，发现一处报错：

经过初步排查发现是依赖版本问题

疑问

我不禁就有了疑问，我明明引入的grpc版本是1.54.0，为啥子编译完是1.31.1？
为了验证我的疑问是合理的，通过mvn dependency:tree 命令以及版本对比，更加增加了我的疑惑。如下图，grpc-netty-shaded依赖中的grpc-core确确实实是1.54.0，为啥子就成了1.31.1了？无中生有？

排查过程

起初我怀疑是dubbo-bom的问题，不会呀，dubbo-bom在父工程中以dependencyManagement形式存在，我没有引入依赖它是不会传递的呀？随即立马打消了这个疑问

然后开始没有目的的百度😂maven版本冲突问题？ ，结果是没有任何头绪，只有Maven Helper插件帮忙解决冲突问题，但是我想知道的是为什么会冲突。

紧接着又去github上提了一个issue 为什么根据官方提供的依赖出现版本冲突问题？ 😂

过了一天后看没人回答，想了想难道真的是dubbo bom问题？ 于是我注释了dubbo bom的依赖，可以了！！！ 这是为什么？我没有引入dubbo bom任何依赖呀？难道是这个scope导致的？

于是我又继续百度 maven denpendency scope 😂 ，这些结果要么没有对scope为import的说明，要么就是很含糊抽象，看上去跟我之前的理解一样。

由于百度的结果并不能解决我的问题，所以上maven官网看了下对Dependency Scope的说明

最后定位问题所在。

问题存在的原因

scope为import是指依赖项将被部分中的有效依赖项列表所取代。

这个说明非常具体，一下就打消了我所有的疑惑。因为dubbo-bom中存在dubbo-rpc-grpc依赖项，而其又有grpc的依赖

根据官网上的说明，我在子工程中声明版本为1.54.0的grpc依赖项会被其所替代。

所以出现了这个问题😂

总结

通过这次版本冲突问题，让我意识到我对maven的了解远远不够。平时只是对其使用，出现冲突直接解决，并不会去深究为什么。也是通过这次的问题让我对maven多了点了解，让我对解决问题的方式更加深刻：遇到问题不要上来就百度😂，要学会分析、要学会在官网上寻找问题所在，要对一个知识有全面的了解。

示例依赖版本说明

dubbo-bom依赖如下

<dependency>
  <groupId>org.apache.dubbo</groupId>
  <artifactId>dubbo-bom</artifactId>
  <version>$dubbo.version</version>
  <type>pom</type>
  <scope>import</scope>
</dependency>

grpc依赖如下

<dependency>
  <groupId>io.grpc</groupId>
  <artifactId>grpc-netty-shaded</artifactId>
  <version>1.54.0</version>
  <scope>runtime</scope>
</dependency>
<dependency>
  <groupId>io.grpc</groupId>
  <artifactId>grpc-protobuf</artifactId>
  <version>1.54.0</version>
</dependency>
<dependency>
  <groupId>io.grpc</groupId>
  <artifactId>grpc-stub</artifactId>
  <version>1.54.0</version>
</dependency>
<dependency> <!-- necessary for Java 9+ -->
  <groupId>org.apache.tomcat</groupId>
  <artifactId>annotations-api</artifactId>
  <version>6.0.53</version>
  <scope>provided</scope>
</dependency>

maven打包时的三方包的选择顺序

在一个项目有多个模块引用多个版本的某个插件(或者叫三方包、jar包等)时，如何解决版本冲突问题？最终选用某个版本还是选择几个版本？

maven在遇到上面的情况时，会智能处理版本冲突，最终选择一个版本，选取的原则是：

1、就近原则：根据依赖路径最短选择版本

2、路径相同选择最先出现的，及第一声明原则

 

那么问题来了，当有多个模块引用同一个版本时，如何查看依赖路径？如果路径长度相同，哪个最先出现？

首先在根pom或者父pom中引入maven-dependency-plugin这个插件，在项目的根目录执行命令mvn dependency:tree可以查看jar包的依赖顺序，如图，可以清楚的查看某个jar的依赖路径；

使用命令mvn dependency:tree -Dverbose可以查看查看更详细的信息，主要是告诉你那些版本因为冲突而被忽略

 

 使用mvn dependency:list，可以列出依赖的所有jar包

执行错误的命令，可以查看这个插件的所有命令：项目中，我常用mvn dependency:copy-dependencies -DoutputDirectory=~/dependencies命令把项目的所有依赖拷贝到一个目录里。

但是这个方法存在一个问题：就是它只解决模块内部的版本冲突，并没有解决项目各个模块之间的依赖冲突，因此有的时候会存在多个jar包的现象，以至于你也说不清用户最终使用的是哪个版本的jar包，也就无法明确判断用户使用的jar包到底违不违反部门确定的“必须使用某个jar包的规定”

联想：pip install pyquery==2.2.222222一个错误的版本号，通过错误信息，你可以看到所有支持的正确的版本，这样再选择一个正确的版本

 

为了解决mvn dependenc:copy-dependencies上面存在的多个版本的问题，一个比较笨拙的解决办法是：使用mvn depedency:tree > tree.txt 把依赖及依赖路径信息拷贝到某个目录，然后使用py脚本把这些目录的内容存入数据库，当遇到多个版本的情况时，把这些tree.txt里的内容再拿出来，进行分析：

分析方法就是，对tree.txt进行每行匹配，找到某个插件出现在路径里的顺序以及版本号信息，找到那个maven最终使用的版本

如图，通过查看版本名字和‘[INFO]’之间字符的个数来确定路径，1个字符是路径值是1，4个字符路径值是2，依次类推。

 

还有另外一个方法：就是找到项目最终部署的目录，已经目录下的pom.xml文件，然后对这个目录进行mvn dependency:copy-dependencies -DoutputDirectory=~/dependencies，这样就可以得到项目最终的依赖列表。比如下面的项目目录下的web目录就是项目最终打包的配置