点击上方名片关注我,为你带来更多踩坑案例
引导
当你没时间阅读厚厚的书籍
或者厌倦了长篇大论的面经
那么这个系列适合你
只需要在地铁上、吃饭时、厕所里,几分钟的时间就可以获得一个小知识
每天一点小进步,日积月累之下你会感谢自己
请关注我,持续为您带来更新
小知识
你是否遇到过依赖冲突呢?
特别是在创建新的项目或者引入新的依赖的时候
No Such Method XXX
上面的报错相信大家都遇到过
90%的情况是因为依赖冲突导致jar包版本不一致的情况导致的
(剩下10%的情况,就是自己写错了)
依赖冲突
简单的叙述一下依赖冲突:
你项目pom中依赖了A、B两个jar包
A依赖了X,且依赖的X版本为1.2.0
B依赖了Z,Z又依赖了X,且依赖的X版本是1.1.0
这个时候A和B就是依赖冲突了,因为依赖是有传递性的
那么依赖冲突又会导致什么问题呢?
这时候你想使用X中的一个方法method,但是method报错,找不到该方法
那么你去看看相应的jar包,你引用的X绝对是1.2.0,且1.2.0中的method的方法应该已经被移除了。因为依赖冲突的时候,是会有一个冲突管理策略的
按照以下优先级:
1. 优先dependencyManagement,也就是你项目pom中直接引用的jar包版本,相应的这也是一个解决依赖冲突的方法,在自己的pom中明确定义要使用的有冲突的jar包版本
2. 优先最短路径,也就是上文中,A->1.2.0X,B->Z->1.1.0X,最后引用的是1.2.0X
3. 同一pom中,优先声明原则,谁在上面引用谁
排查依赖冲突
上述法则可以让你出现问题的时候,有据可依的解决问题,那么如果想排查一个项目下有可能存在的依赖冲突,又该怎么做呢?
推荐一个idea插件-Maven-Helper
它的一大作用就是可视化分析并解决项目中的依赖冲突
比如装好以后
以上图中fastjson为例,1.2.69是当前使用的版本,也是项目pom中明确引用的版本,飘黄的1.2.83则是spring-boot所依赖的
像这种情况尽量使用高版本,把自己pom中的1.2.69->1.2.83
再来举一个例子
像这种的,就是依赖的jar包比我项目中明确引用的jar包版本要低,可以右键-exclude,一键排除掉
类似的情况都可以通过它来排除,让你的项目变得更健壮,杜绝隐患
当然,他还有其他用途,比如项目启动的时候,发现一个警告
c.n.c.sources.URLConfigurationSource : No URLs will be polled as dynamic configuration sources.
这个警告就是说你eureka下有一个动态配置中心archaius组件,它配置有问题。
但是我这里并不想用eureka下的这个组件,因为已经有spring-config了
这个时候就需要把它剔除掉
就可以在maven-helper界面搜索
然后轻轻松松剔除
快去检查一下你的项目下是否有依赖冲突吧!