一个简单粗暴的定位冲突jar的方法

本文介绍了一种有效定位并解决Maven项目中Jar包冲突的方法,通过逐步排除和二分法定位,最终确定了导致启动异常的具体冲突Jar包,并提供了修改依赖的解决方案。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

这是一个简单粗暴的定位冲突jar的方法

项目中加了三个jar依赖之后 启动时就报错,去掉之后 运行正常

<dependency>
            <groupId>org.apache.hadoop</groupId>
            <artifactId>hadoop-common</artifactId>
            <version>${hadoop.version}</version>
        </dependency>
        <dependency>
            <groupId>org.apache.hive</groupId>
            <artifactId>hive-jdbc</artifactId>
            <version>${hive.version}</version>
        </dependency>
        <dependency>
            <groupId>org.apache.hive</groupId>
            <artifactId>hive-common</artifactId>
            <version>${hive.version}</version>
        </dependency>

判断是这个三个jar与 原有jar冲突

经过几轮尝试之后缩小范围 是 hive-jdbc  与hive-common 中的包存在冲突 与hadoop-common无关

尝试定位具体的冲突jar

1、根据具体错误百度 得到的很多都是配置文件写错 很显然不符合

2、因为项目依赖的包比较多 ,在加入上面三个包前就有30个jar冲突了 ,不过并没有影响项目正常运行,加入上面3个jar之后 多了10个冲突 ,首先把这多出来10个做exclusions排除 项目依然启不起来,把40个冲突的jar全部做排除 项目依然启不起来

以上尝试都没能定位到具体是哪个包冲突导致启动异常

突然想到一个办法:根据pom.xml全部排出,如果不报错 再定位具体的jar

点击

跳转进去查看所有依赖

把pom.xml中所有的依赖拷贝出来改成排除 贴到我项目中引用 hive-jdbc 的包中

同理hive-common 也根据pom.xml文件中依赖的包全都去掉

运行一下试试 果然正常了

然后就是在这些exclusion 中定位具体是哪一个了 范围已经确定剩下的就是使用二分法 一半一半的排除了 

最终找到是这个包导致的冲突

 <groupId>org.eclipse.jetty.aggregate</groupId>
   <artifactId>jetty-all</artifactId>

改下依赖就OK了

  <dependency>
            <groupId>org.apache.hive</groupId>
            <artifactId>hive-jdbc</artifactId>
            <version>${hive.version}</version>
            <exclusions>
                <exclusion>
                    <groupId>org.eclipse.jetty.aggregate</groupId>
                    <artifactId>jetty-all</artifactId>
                </exclusion>
            </exclusions>
        </dependency>
        <dependency>
            <groupId>org.apache.hive</groupId>
            <artifactId>hive-common</artifactId>
            <version>${hive.version}</version>
            <exclusions>
                <exclusion>
                    <groupId>org.eclipse.jetty.aggregate</groupId>
                    <artifactId>jetty-all</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

 

不过我用这个命令 mvn -X compile dependency:tree -Dverbose >a.log打印所有冲突的jar并没有jetty-all 这个包冲突,所以我上面尝试定位的第二种方法 才没有找到真正的冲突jar

 

 

 

 

### Maven依赖爆红的原因分析 Maven依赖爆红通常表示项目无法正确解析某些依赖项,可能由多种原因引起。以下是常见的几个方面: 1. **网络连接问题** 如果项目的POM文件中定义的依赖来自远程仓库(如Maven中央仓库),而当前环境下的网络连接不稳定或受限,则可能导致依赖下载失败[^1]。 2. **依赖版本冲突** 当多个模块引入同一个库的不同版本时,可能会发生版本冲突,从而导致部分依赖无法加载成功[^2]。 3. **私服配置错误** 若项目使用的是一些私有组件而非公开可用的资源,则需确认其对应的`<repository>`地址是否正确设置于settings.xml或pom.xml之中;另外还需注意权限验证等问题是否存在影响访问的情况[^3]。 4. **本地缓存损坏** 在多次构建过程中可能出现个别文件未完全下载完成的现象,进而造成后续操作异常提示“找不到类”等情况显示为红色标记警告信息。 --- ### 解决方案汇总 #### 方法一:刷新并强制更新SNAPSHOT版本 执行以下命令来清理旧数据重新获取最新状态: ```bash mvn clean install -U ``` 上述指令中的参数-U代表强制从远端拉取最新的快照版(SNAPSHOT),适用于当开发者怀疑自己所处环境中存储着过期副本的情形下尝试修复问题。 #### 方法二:手动安装缺失JAR包至本地仓储 对于那些仅存在于内部服务器上的特殊制品而言,可以采用如下方式将其加入到个人电脑里的.m2目录结构里面去以便正常使用它们的功能特性。 假设目标路径指向某个具体位置的话,那么就可以按照下面给出的例子来进行实际处理动作了: ```bash mvn install:install-file \ -Dfile=/path/to/your.jar \ -DgroupId=com.example.custom \ -DartifactId=custom-library \ -Dversion=1.0.0 \ -Dpackaging=jar ``` 这里需要注意替换相应的字段值以匹配实际情况需求。 #### 方法三:检查setting.xml与pom.xml配置一致性 仔细核对全局级别以及项目特定范围内的XML文档内容是否有误设之处,并确保所有必要的认证凭据均已妥善提供给工具链知晓如何合法进入受保护区域取得所需资料。 #### 方法四:删除有问题的本地缓存重试 定位到`.m2/repository`文件夹底下找到疑似存在问题的那个子树节点之后果断删掉它再让IDE自动同步一次试试看效果怎样样呢?这招数简单粗暴却往往能够奏效哦! --- ### 总结说明 综上所述,针对不同场景采取合适的策略组合拳出击即可有效应对绝大多数关于MAVEN DEPENDENCY RED ERROR方面的挑战啦!当然咯,在日常工作中也要养成良好习惯比如定期整理工作区保持整洁有序等等预防措施也是非常重要的哈😊
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值