maven依赖冲突

最新推荐文章于 2024-07-26 12:22:10 发布
最新推荐文章于 2024-07-26 12:22:10 发布
阅读量138 收藏
点赞数
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_34971162/article/details/81304557
版权

Maven的依赖管理

依赖配置

<project> 
 ...
  <dependencies>  
    <dependency>  
      <groupId>...</groupId>  
      <artifactId>...</artifactId>  
      <version>...</version>
      <type>...</type>
      <scope>...</scope>
      <optional>...</optional>
      <exclusions>  
        <exclusion>  
          <groupId>...</groupId>  
          <artifactId>...</artifactId>  
        </exclusion>
         ...
      </exclusions>  
    </dependency> 
     ...
  </dependencies> 
  ... 
</project>

根元素下project下的dependencies可以包含一个或者多个dependency元素，以声明一个或者多个项目依赖。每个依赖可以包含的元素有：

  • groupId,artifactId和version：依赖的基本坐标，对于任何一个依赖来说，基本坐标是最重要的，Maven根据坐标才能找到需要的依赖。
  • type：依赖的类型，对应于项目坐标定义的packaging。大部分情况下，该元素不必声明，其默认值是jar。
  • scope：依赖的范围
  • optional：标记依赖是否可选。
  • exclusions：用来排除传递性依赖

  • 大部分依赖声明只包含基本坐标

依赖范围

Maven在编译主代码的时候需要使用一套classpath,在编译和执行测试的时候会使用另一套classpath,实际运行项目的时候，又会使用一套classpath。

依赖范围就是用来控制依赖与这三种classpath（编译classpath、测试classpath、运行classpath）的关系，Maven有以下几种依赖范围：

  • compile：编译依赖范围。如果没有指定，就会默认使用该依赖范围。使用此依赖范围的Maven依赖，对于编译、测试、运行三种classpath都有效。典型的例子是spring-core，在编译，测试和运行的时候都需要使用该依赖。
  • provided：已提供依赖范围。使用此依赖范围的Maven依赖，对于编译和测试classpath有效，但在运行时无效。典型的例子是servlet-api，编译和测试项目的时候需要该依赖，但在运行项目的时候，由于容器已经提供，就不需要Maven重复地引入一遍。
  • test：测试依赖范围。使用此依赖范围的Maven依赖，只对于测试classpath有效，在编译主代码或者运行项目的使用时将无法使用此类依赖。典型的例子就是JUnit，它只有在编译测试代码及运行测试的时候才需要。
  • runtime：运行时依赖范围。使用此依赖范围的Maven依赖，对于测试和运行classpath有效，但在编译主代码时无效。典型的例子是JDBC驱动实现，项目主代码的编译只需要JDK提供的JDBC接口，只有在执行测试或者运行项目的时候才需要实现上述接口的具体JDBC驱动。
  • system：系统依赖范围。该依赖范围与provided所表示的依赖范围一致，对于编译和测试classpath有效，但在运行时无效。只是使用system范围依赖时必须通过systemPath元素显式地指定依赖文件的路径。由于此类依赖不是通过Maven仓库解析的，而且往往与本机系统绑定，可能造成构建的不可移植，因此应该谨慎使用，systemPath元素可以引用环境变量。

传递性依赖

传递性依赖是在maven2中添加的新特征，这个特征的作用就是你不需要考虑你依赖的库文件所需要依赖的库文件，能够将依赖模块的依赖自动的引入。例如我们依赖于spring的库文件，但是spring本身也有依赖，如果没有传递性依赖那就需要我们了解spring项目依赖，自己添加到我们的项目中。有了传递性依赖机制，在使用Spring Framework的时候就不用去考虑它依赖了什么，也不用担心引入多余的依赖。Maven会解析各个直接依赖的POM，将那些必要的间接依赖，以传递性依赖的形式引入到当前的项目中。

例如：项目中用到spring-core，而它又依赖commons-logging，从其构件POM http://repo1.maven.org/maven2/org/springframework/spring-core/4.3.2.RELEASE/spring-core-4.3.2.RELEASE.pom中可以看出

<?xml version="1.0" encoding="UTF-8"?>
 
-<project xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://maven.apache.org/POM/4.0.0" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
 
<modelVersion>4.0.0</modelVersion>
 
<groupId>org.springframework</groupId>
 
<artifactId>spring-core</artifactId>
 
<version>4.3.2.RELEASE</version>
 
<name>Spring Core</name>
 
<description>Spring Core</description>
 
<url>https://github.com/spring-projects/spring-framework</url>
 
 
-<organization>
 
<name>Spring IO</name>
 
<url>http://projects.spring.io/spring-framework</url>
 
</organization>
 
 
-<licenses>
 
 
-<license>
 
<name>The Apache Software License, Version 2.0</name>
 
<url>http://www.apache.org/licenses/LICENSE-2.0.txt</url>
 
<distribution>repo</distribution>
 
</license>
 
</licenses>
 
 
-<developers>
 
 
-<developer>
 
<id>jhoeller</id>
 
<name>Juergen Hoeller</name>
 
<email>jhoeller@pivotal.io</email>
 
</developer>
 
</developers>
 
 
-<scm>
 
<connection>scm:git:git://github.com/spring-projects/spring-framework</connection>
 
<developerConnection>scm:git:git://github.com/spring-projects/spring-framework</developerConnection>
 
<url>https://github.com/spring-projects/spring-framework</url>
 
</scm>
 
 
-<issueManagement>
 
<system>Jira</system>
 
<url>https://jira.springsource.org/browse/SPR</url>
 
</issueManagement>
 
 
-<dependencies>
 
 
-<dependency>
 
<groupId>commons-codec</groupId>
 
<artifactId>commons-codec</artifactId>
 
<version>1.10</version>
 
<scope>compile</scope>
 
<optional>true</optional>
 
</dependency>
 
 
-<dependency>
 
<groupId>commons-logging</groupId>
 
<artifactId>commons-logging</artifactId>
 
<version>1.2</version>
 
<scope>compile</scope>
 
</dependency>
 
 
-<dependency>
 
<groupId>log4j</groupId>
 
<artifactId>log4j</artifactId>
 
<version>1.2.17</version>
 
<scope>compile</scope>
 
<optional>true</optional>
 
</dependency>
 
 
-<dependency>
 
<groupId>net.sf.jopt-simple</groupId>
 
<artifactId>jopt-simple</artifactId>
 
<version>5.0.2</version>
 
<scope>compile</scope>
 
<optional>true</optional>
 
</dependency>
 
 
-<dependency>
 
<groupId>org.aspectj</groupId>
 
<artifactId>aspectjweaver</artifactId>
 
<version>1.8.9</version>
 
<scope>compile</scope>
 
<optional>true</optional>
 
</dependency>
 
</dependencies>
 
</project>

可以看出还依赖了其他构建。Maven就是根据此POM文件获得它的依赖的，从而实现传递性依赖。

 假设A依赖于B，B依赖于C，我们说A对于B是第一直接依赖，B对C是第二直接依赖，A对于C是传递性依赖。第一直接依赖的范围和第二直接依赖的范围决定了传递性依赖的范围。

假设A依赖于B，B依赖于C，我们说A对于B是第一直接依赖，B对C是第二直接依赖，A对于C是传递性依赖。第一直接依赖的范围和第二直接依赖的范围决定了传递性依赖的范围。

最左边一行表示第一直接依赖范围，最上面一行表示第二直接依赖范围，中间的交叉单元格则表示传递性依赖范围。

 compiletestprovidedruntime
compilecompile------runtime
testtest------test
providedprovided---providedprovided
runtimeruntime------runtime

 

  • 当第二直接依赖的范围是compile的时候，传递性依赖的范围与第一直接依赖的范围一致；
  • 当第二直接依赖的范围是test的时候，依赖不会得以传递；
  • 当第二直接依赖的范围是provided的时候，只传递第一直接依赖的范围也为provided的依赖，切传递性依赖的范围同样为provided；
  • 当第二直接依赖的范围是runtime的时候，传递性依赖的范围与第一直接依赖的范围一致，但compile例外，此时传递性依赖的范围为runtime。

maven对传递性依赖的处理

有些依赖，maven会对其按照下述原理自动处理

1）.短路优先：谁离得最近就使用谁的依赖jar包

C到达A为C->B->A

C到达B为C->B

例如：

A中的 commons-io的版本为2.4

B中的commons-io的版本为2.0

C中依赖于B,B依赖于A

则C的junit的包为2.0版本

因为依赖的短路优先

2）.如果两条路都是一样长的时候呢？

C到达A为C->A

C到达B为C->B

则看pom文件中依赖的两个工程谁在前面就是用哪个版本

例如：

这里使用的common-io为2.4版本也就是A的jar包

        <dependency>
            <groupId>org.lonecloud.A</groupId>
            <artifactId>A</artifactId>
            <version>0.0.1-SNAPSHOT</version>
        </dependency>
        <!--C依赖于B但是会将A的依赖传递进来 -->
        <dependency>
            <groupId>org.lonecloud.B</groupId>
            <artifactId>B</artifactId>
            <version>0.0.1-SNAPSHOT</version>
            <!-- 此标签的作用是可以将B的传递依赖关系A不传递给C -->
            <!-- <exclusions> <exclusion> <groupId>org.lonecloud.A</groupId> <artifactId>A</artifactId> 
                </exclusion> </exclusions> -->
        </dependency>

C文件中添加了A和B的依赖项的时候谁最先加载则使用谁的jar包

下面使用的是2.0的版本，也就是B中的jar包

        <dependency>
            <groupId>org.lonecloud.B</groupId>
            <artifactId>B</artifactId>
            <version>0.0.1-SNAPSHOT</version>
            <!-- 此标签的作用是可以将B的传递依赖关系A不传递给C -->
            <!-- <exclusions> <exclusion> <groupId>org.lonecloud.A</groupId> <artifactId>A</artifactId> 
                </exclusion> </exclusions> -->
        </dependency>
        <dependency>
            <groupId>org.lonecloud.A</groupId>
            <artifactId>A</artifactId>
            <version>0.0.1-SNAPSHOT</version>
        </dependency>

Maven依赖jar包冲突解决

1、判断jar是否正确的被引用

1）、在项目启动时加上VM参数：-verbose:class

项目启动的时候会把所有加载的jar都打印出来 类似如下的信息：

classpath加载的jar

具体load的类

我们可以通过上面的信息查找对应的jar是否正确的被依赖，具体类加载情况，同时可以看到版本号，确定是否由于依赖冲突造成的jar引用不正确；

2）、 通过maven自带的工具：‍‍mvn dependency:tree

具体后面可以加 -Dverbose 参数 ，详细参数可以去自己搜，这里不详细介绍。

比如分析如下POM

运行： mvn dependency:tree -Dverbose

输出结果:

通过里面的信息可以看到 两个jar都commons-logging存在依赖，但是版本不同。里面的详细信息显示引用了 commons-logging:commons-logging:jar:1.1 去掉了commons-logging:commons-logging:jar:1.0.3 （omitted for duplicate）。

3）、在Myeclipse或者idea或者eclipse中用pom编辑器打开一个pom文件，在Dependency Hierarchy的Tab页中，就可以查看当前pom文件中显示声明的jar包，及这些显示声明的jar中隐式引入的依赖jar包。

这样就可以查看有哪些隐式的依赖jar会导致jar包冲突了。

通过以上方法我们可以看到项目中引用jar版本号；接下来就是如何排除掉我们不想要版本的jar;

2、冲突的解决

1）在pom.xml中引用的包中加入exclusion，排除依赖

<dependency>
			<groupId>com.alibaba</groupId>
			<artifactId>dubbo</artifactId>
			<version>2.5.3</version>
			<exclusions>
				<exclusion>
					<artifactId>spring</artifactId>
					<groupId>org.springframework</groupId>
				</exclusion>
			</exclusions>
		</dependency>

去除全部依赖

<dependency>
<groupId>com.alibaba</groupId>
<artifactId>dubbo</artifactId>
<version>2.5.3</version>
<exclusions>
<exclusion>
<artifactId>*</artifactId>
<groupId>*</groupId>
</exclusion>
</exclusions>
</dependency>

 

飞雪冬玉花
关注
Maven jar包冲突的解决方案
08-19
主要介绍了Maven jar包冲突的解决方案,文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下
Maven的传递性依赖及其jar包冲突解决
honghailiang的专栏
11-03 2万+
一、Maven简介 Maven是一个跨平台的项目管理工具。作为Apache组织的一个颇为成功的开源项目，其主要服务于基于Java平台的项目创建，依赖管理和项目信息管理。 二、Maven的依赖管理 1、依赖配置 基本配置： ... ... ...
Maven依赖冲突
weixin_44161478的博客
07-26 296
比如类 C 在 Jar 包 A、B 中都存在，且两个版本的 C 都出现在相同级别（Bootstrap、Extension、Application等）的类路径下，那么类加载的先后顺序就决定了 JVM 选择的最终版本（根据双亲委派机制，先被加载的类会阻止后面的类继续加载，防止核心类被覆盖掉），选择了错误的 C 会导致出现上述第二类依赖冲突。为了解决这类问题，需要把不是目标类的那个依赖排除。先来后到原则：当依赖链长度相同时，即A-X(1.0)和A-X(2.0) 的情况，会按照依赖的声明顺序决定采用哪个版本。
Maven中 jar包冲突原理与解决办法
热门推荐
noaman_wgs的博客
07-20 10万+
Maven中jar包冲突是开发过程中比较常见而又令人头疼的问题，我们需要知道 jar包冲突的原理，才能更好的去解决jar包冲突的问题。本文将从jar包冲突的原理和解决两个方面阐述Maven中jar包冲突的解决办法。
解决Maven中使用很多本地jar包的编译问题
AndersonMao的专栏
01-20 1万+
Maven依赖本地非repository中的jar包，依赖jar包放在WEB-INF/lib等目录下的情况客户端编译出错的处理。 http://www.mamicode.com/info-detail-169419.html Maven提供了scope为system的依赖，文档的原文如下： system This scope is similar to provided except t
Maven 解决jar包冲突的原理
红豆和绿豆的博客
12-28 1万+
管理包依赖是 Maven 核心功能之一，下面通过如何引入 jar 包；如何解析 jar 包依赖；包冲突是如何产生；如何解决包冲突；依赖管理解决什么问题；什么是依赖范围；使用包依赖的最佳实践等 6 个问题来介绍。 如何引入 jar 包 在代码开发时，如果需要使用第三方 jar 包提供的类库，那么需要在 pom.xml 加入该 jar 包依赖。 例如：使用 zookeeper client depe
详解maven依赖冲突以及解决方法
08-19
maven依赖冲突及解决方法 maven依赖冲突是指项目依赖的某一个jar包，有多个不同的版本，因而造成类包版本冲突。这种情况下，项目可能会出现无法编译或运行的错误。 依赖冲突的原因： 依赖冲突很经常是类包之间的...
解决Maven依赖冲突
最新发布
09-08
对于第二类依赖冲突，同名类存在于多个不同的依赖 jar 包当中，这种情况是 Maven 无法解决的，因为 Maven 只会为你针对同一个 Jar 包的不同版本进行仲裁，而这俩是属于不同的 Jar 包，超出了 Maven 的依赖管理范畴。...
maven依赖冲突插件 MavenHelper-4.26.0
03-12
maven依赖冲突插件：idea依赖很多的时候 可以使用插件帮我们快速查看冲突的依赖 并快速的解决依赖
试试 IDEA 解决 Maven 依赖冲突的高能神器.docx
11-17
总的来说，解决Maven依赖冲突需要理解其工作原理，结合IDEA提供的工具，如Maven Helper插件和依赖结构图，可以有效地定位和排除冲突，保持项目的稳定性和可维护性。在实际开发中，避免引入不必要的依赖和定期清理...
关于Maven依赖冲突
FromZeroJiYuan的博客
11-25 720
文章目录Maven依赖冲突场景场景1-重构同包同名类场景2-同包同名类与环境兼容性场景3-同包同名类内部逻辑不同综上Maven依赖传递Maven依赖传递包选择逻辑-仲裁机制Maven scope属性Maven冲突处理工具Maven依赖树命令Maven依赖冲突解决排除冲突依赖父pom中统一管理版本Maven可选依赖总结 Maven依赖冲突场景 场景1-重构同包同名类 假设有两个业务B和C依赖基础包A，后维护基础包A的团队重构基础包A，并打了一个新的基础包D发布。 在一次业务改动时，业务B引入新的基础包D，在开
Maven类包冲突终极解决小技若干
08-28
Maven类包冲突终极解决小技若干
Maven如何解决jar包冲突的问题?
zhangjiaming_zjm的博客
04-24 962
如果在应用中，我们同时依赖了两个第三方的jar包A，B，而A，B中又都依赖了C包，但是依赖的C的版本不同，那么就可能发生jar包冲突，导致最终编译打包后，应用的classpath中只有一个C的jar包。那么，因为maven有一定的Jar包依赖传递原则，所以有可能他最终选择的jar包并不是我们真正想用的，那这时候怎么办呢?打印出来的就是整个项目的jar包依赖的一个树形结构，我们找到发生了冲突的jar包就可以查看他的多种不同版本的依赖路径了。这样，在项目中，就只会依赖X，而X依赖的Y的对应版本就会被排除了。
Web基础之Maven包冲突
追本溯源的专栏
11-25 927
这篇文章简单的记录maven包冲突导致tomcat7：run命令无法启动项目的问题，并说明了如何使用eclipse来查看maven项目的包依赖关系
maven解决包冲突
查拉图斯特拉talk的博客
01-17 1223
这边篇文章主要是来讲解我们日常开发中碰到一些Maven包冲突的一个解决方案。如何去一步一步进行排查，然后找到思路解决某一个固定的痛点和问题。在我们日常的导入包当中，可能不经意间就会导入一些相同类名的包或者路径的包。因为不同的包，它可能依赖某一个版本的可能不是同一个版本，这样就会导致一个冲突产生。可能版本不一致也有一定的原因。最后我想说的是当发现一个问题的时候，我们需要逐步拆解，一步一步找到我们需要处理的问题的点。不得不说idea这个编辑器还是非常强大的。今天这篇文章主要是对我的一个解决冲突的一个思路的回顾。
【Maven】Maven 基础教程（五）： jar 包冲突问题
书山有路，学海无涯。记录成长，追逐梦想
03-07 1533
编订依赖列表的程序员，初次设定一组依赖，因为尚未经过验证，所以确实有可能存在各种问题，需要做有针对性的调整。那么谁来做这件事呢？我们最不希望看到的就是：团队中每个程序员都需要自己去找依赖，即使是做同一个项目，每个模块也各加各的依赖，没有统一管理。那前人踩过的坑，后人还要再踩一遍。而且大家用的依赖有很多细节都不一样，版本更是五花八门，这就让事情变得更加复杂。
Maven使用中常见的包冲突问题，以及Jar包管理
Scalzdp的专栏
12-07 678
JAR包冲突是指在一个项目中引入了两个或多个不同版本的JAR包，而这些JAR包中都包含有相同名称的类、接口、资源等，从而引起冲突。这种冲突通常发生在项目构建和运行时，导致程序无法正确地找到所需的类或资源，从而报错。通常会抛出一个ClassNotFoundException这样的异常。
maven 解决jar包冲突
ye___li的博客
05-07 142
1.发现jar包版本冲突 2.查找低版本jar依赖，找到maven jar包依赖图位置 3.搜索jar包 ctrl+F 3.pom.xml找到上级依赖jar,进入依赖jar的pom文件（groupId上ctrl+鼠标左键），找到对应依赖。 4.找到jar包 5.排除依赖 ...
Maven依赖冲突深度解析与解决策略
本文将深入解析Maven依赖冲突的本质，原因，以及提供有效的解决方案。 首先，让我们理解什么是依赖冲突。在Maven项目构建过程中，每个模块都有自己的pom.xml文件，其中定义了所需的依赖项。当两个或更多的模块依赖...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值