当前位置: 首页 > 工具软件 > x-redis > 使用案例 >

spring-data-redis和spring版本冲突原因

庄实
2023-12-01

这块冲突还是挺难受的,解决方案链接

https://my.oschina.net/u/3714931/blog/1607973

具体解决问题步骤:


项目开发过程中,经常会遇到jar冲突,然后maven根据自己的规则进行冲突解决,导致项目在运行的过程中报错。

1、maven自动解决依赖冲突的规则是什么?

2、如何查看当前项目的maven的依赖树?

3、如何从依赖树中找到自己预期的版本,是被那个jar给覆盖了?

4、如何人工进行依赖冲突解决,达到使用目的?

1、maven自动解决依赖冲突的规则是什么?
第一原则:路径最近者优先
项目A有如下的依赖关系:

A->B->C->X(1.0)

A->D->X(2.0)

则该例子中,X的版本是2.0

 

第二原则:路径相等,先声明者优先
项目A有如下的依赖关系:

A->B->Y(1.0)

A->C->Y(2.0)

若pom文件中B的依赖坐标先于C进行声明,则最终Y的版本为1.0

递归依赖的关系列的算是比较清楚了,每行都是一个jar包,根据缩进可以看到依赖的关系。
最后写着compile的就是编译成功的。
最后写着omitted for duplicate的就是有jar包被重复依赖了,但是jar包的版本是一样的。
最后写着omitted for conflict with xxxx的,说明和别的jar包版本冲突了,而该行的jar包不会被引入。比如上面有一行最后写着omitted for conflict with 3.4.6,那么该行的zookeeper:jar:3.4.8不会被引入,会引入3.4.6版本

最后写着version managed from 2.3 ;omitted for duplicate ,表示最终使用commons-pool2最终会使用2.4.2,拒绝使用<dependencyManagement></dependencyManagement>中声明的2.3版本

最后写着version managed from 1.16.8 ;表示最终使用lombok:jar:1.16.22版本

依赖库命名规则:    
${groupId.part1}/${groupId.part2}/${version}    
例:com/alibaba/share/1.4    
    
依赖库文件命名规则:    
${artifactId}-${version}-${classifier}.${type}    
例:test-1.4-source.jar    
    
注:classfier即分类器,多数的时候是用不到的,不过有写情况需要,例:    
TestNG强制需要你提供分类器,以区别jdk14和jdk15    
<dependency>      
   <groupId>org.testng</groupId>      
   <artifactId>testng</artifactId>      
   <version>5.7</version>      
   <classifier>jdk15</classifier>      
</dependency>    

上面的scope即约定依赖范围。 
compile:默认值,一直可用,最后会被打包 
provided:编译期间可用,不会被传递依赖,不会被打包。例:依赖于web容器中的提供的一个jar包,在编译的时候需要加入依赖(web容器还没有介入),运行的时候由web容器来提供。 
test:执行单元测试时可用,不会被打包,不会被传递依赖 
runtime:运行和测试时需要,但编译时不需要 
system:不推荐使用

查看那些jar包依赖了冲突包的命令

mvn dependency:tree -Dverbose -Dincludes=Dincludes=org.springframework:spring-tx

过滤串使用groupId:artifactId:version的方式进行过滤,可以不写全啦,如:

mvn dependency:tree -Dverbose -Dincludes=asm:asm  

 类似资料: