Maven项目中的依赖出现版本冲突,最终发现是对Dependency Scope理解有误
Posted 叫我二蛋
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Maven项目中的依赖出现版本冲突,最终发现是对Dependency Scope理解有误相关的知识,希望对你有一定的参考价值。
再来个文章目录
文章目录
本文记录一下遇到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目录就是项目最终打包的配置
以上是关于Maven项目中的依赖出现版本冲突,最终发现是对Dependency Scope理解有误的主要内容,如果未能解决你的问题,请参考以下文章