Maven中jar包冲突的解决方式

举报
经典鸡翅 发表于 2022/02/17 23:19:45 2022/02/17
【摘要】 现象 创建一个maven工程,引入spring-context包。 <dependency> <groupId>org.springframework</groupId> <artifactId>spring-context<...

现象

创建一个maven工程,引入spring-context包。


   
  1. <dependency>
  2. <groupId>org.springframework</groupId>
  3. <artifactId>spring-context</artifactId>
  4. <version>5.0.8.RELEASE</version>
  5. </dependency>

此时看左侧的lib,我们发现引入了一个坐标,多出了很多的jar包,这个现象叫做依赖传递,就是说,当前坐标所依赖的jar包也会一同引入进来,这里的版本都是5.0.8的。


接下来,我们再引入一个springmvc。我们换一个版本,我们引入4.2.4版本

   
  1. <dependency>
  2. <groupId>org.springframework</groupId>
  3. <artifactId>spring-webmvc</artifactId>
  4. <version>4.2.4.RELEASE</version>
  5. </dependency>

我们通过idea给的maven分析图可以看出,mvc和context都依赖与sprng-core一个,依赖的是5.0.8版本,一个依赖的是4.2.4版本。


那么真正加载的是哪个版本呢。是5.0.8版本。

此时就是存在了jar包的冲突问题,那么我们解决这个问题,有三种方式。

声明优先原则

此时我们的pom文件中是先声明的5.0.8版本,后声明的4.2.4版本,我们将其调换顺序。


此时我们发现他们共同依赖的jar包,都变成了4.2.4版本,这就是声明优先原则。

就近优先原则

比如,我们不想调换顺序,我们就是想使用4.2.4版本的spring-core。我们可以单独引入进来。


此时再看,我们发现依赖的spring-core已经变成了4.2.4版本了。

这个就是就近优先原则,就近优先是直接依赖,直接依赖的优先级大于传递依赖的优先级。

排除依赖

这种方式我们可以直接排除spring-context中的spring-core的传递依赖。


再看依赖,此时已经改为4.2.4.

使用exclusions标签的时候,其内部不用写版本号,这是唯一不用写版本号的一种情况。因为他默认就去找当前依赖的版本了。

文章来源: blog.csdn.net,作者:经典鸡翅,版权归原作者所有,如需转载,请联系作者。

原文链接:blog.csdn.net/hanqing456/article/details/111878907

【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。