Maven实战(七)---传递依赖

假设A-->C 
B-->A      ==> B-->C
,A依赖于C是直接依赖,B依赖于A是直接依赖,B依赖于C是传递依赖。

现象一

举个例子:A-->log1.0  B-->log2.0 C-->A,B 那么我们来看依赖关系:

User-core依赖于log4j 1.2.17

<dependency>
			<groupId>log4j</groupId>
			<artifactId>log4j</artifactId>
			<version>1.2.17</version>
		</dependency>

User-log包依赖于log4j 1.2.9

<dependency>
			<groupId>log4j</groupId>
			<artifactId>log4j</artifactId>
			<version>1.2.9</version>
		</dependency>

User-service依赖于user-core,也依赖于user-log

可以看出user-service依赖的log4j的版本号为1.2.9。因为先依赖的log,后依赖于core,user-service依赖log4j相当于间接依赖。因此当有间接依赖的时候先依赖的哪个,就会依赖哪个包的间接依赖。

总结:间接依赖,如果级别相同,依赖于先引用的依赖。

现象二

先依赖于user-core,再依赖于user-log.下面看commons-logging.jar的版本号:

User-core里面的Commons-logging的版本号为1.0.4

User-log里面的Commons-logging的版本号为1.1.1

User-service里面Commons-logging的版本号为1.1.1

按照第一种,user-service里面的jar版本应该为1.0.4,现在为什么是1.1.1呢?

我们来解析:

User-core里面依赖于dbunit,而commons-logging.jar是作为依赖项被引用下来的

User-log里面是直接引用commons-logging.jar

因此它们处于不同的依赖树上,深度越浅越被优先选择。

小结

1.在工程的依赖树上,深度越浅,越被有限选择。

2.若两个依赖包处于依赖树上的同一层,则谁在前选择谁。

总之,避免传递依赖时引起版本问题出现的最佳实践。一般情况下,如果工程直接依赖到某一框架的多个模块,最好全部声明这些依赖。

版权声明:本文为博主原创文章,未经博主允许不得转载。

时间: 2024-11-07 14:00:23

Maven实战(七)---传递依赖的相关文章

Maven实战七

转载:http://www.iteye.com/topic/973166 前言 Maven,发音是[`meivin],"专家"的意思.它是一个很好的项目管理工具,很早就进入了我的必备工具行列,但是这次为了把ABPM项目 完全迁移并应用maven,所以对maven进行了一些深入的学习.写这个学习笔记的目的,一个是为了自己备忘,二则希望能够为其他人学习使用maven 缩短一些时间. maven概要 首先我把maven的概念快速的梳理一下,让我们快速地建立起一个比较精确的maven应用场景.

httpclient版本冲突,maven工程中传递依赖导致的版本冲突

A服务发送http请求调用B服务时,出现异常信息:2020-03-23 10:15:14.001:WARN:oejs.ServletHandler:qtp760563749-27: org.springframework.web.util.NestedServletException: Handler processing failed; nested exception is java.lang.NoClassDefFoundError: org/apache/http/util/Argsat

转】Maven实战(七)---传递依赖

原博文出自于:http://blog.csdn.net/liutengteng130/article/details/47000069   感谢! 假设A-->C  B-->A      ==> B-->C ,A依赖于C是直接依赖,B依赖于A是直接依赖,B依赖于C是传递依赖. 现象一 举个例子:A-->log1.0  B-->log2.0 C-->A,B 那么我们来看依赖关系: User-core依赖于log4j 1.2.17 <dependency>

[Maven实战](9)传递性依赖

了解Spring的朋友都知道,创建一个Spring Framework项目都需要依赖什么样的Jar包.如果不使用Maven,那么在项目中就需要手动下载相关的依赖.由于Spring Framework又会依赖与其他开源类库,因此实际中往往会下载Spring Framework的jar包,还的下载所有它依赖的其他jar包.这么做往往就引入了很多不必要的依赖.另一种做法是只下载Spring Framework的jar包,不包含其他的相关依赖,到实际使用的时候,再根据报错信息,或者查询相关文档,加入需要

Maven实战(六)依赖

我们项目中用到的jar包可以通过依赖的方式引入,构建项目的时候从Maven仓库下载即可. 1. 依赖配置    依赖可以声明如下: <project> ... <dependencies> <dependency> <groupId>group-a</groupId> <artifactId>artifact-a</artifactId> <version>1.0</version> <exc

学习笔记——Maven实战(七)常用Maven插件介绍(上)

我们都知道Maven本质上是一个插件框架,它的核心并不执行任何具体的构建任务,所有这些任务都交给插件来完成,例如编译源代码是由maven-compiler-plugin完成的.进一步说,每个任务对应了一个插件目标(goal),每个插件会有一个或者多个目标,例如maven-compiler-plugin的compile目标用来编译位于src/main/java/目录下的主源码,testCompile目标用来编译位于src/test/java/目录下的测试源码. 用户可以通过两种方式调用Maven插

《Maven实战》整理三:坐标和依赖

1.1 何为Maven坐标 正如之前所说的,Maven的一大功能就是管理项目依赖.为了能自动化地解析任何一个Java构件,Maven就必须将它们唯一标识,这就依赖管理的底层基础——坐标. 1.2 坐标详解 Maven坐标的元素包括:groupId,artifactId.version.packaging.classifier.先看一组坐标定义,如下: <groupId>org.sonatype.nexus</groupId> <artifactId>nexus-inde

Maven实战(七,八)——经常使用Maven插件介绍

我们都知道Maven本质上是一个插件框架,它的核心并不运行不论什么详细的构建任务,全部这些任务都交给插件来完毕,比如编译源代码是由maven-compiler-plugin完毕的.进一步说,每一个任务相应了一个插件目标(goal),每一个插件会有一个或者多个目标,比如maven-compiler-plugin的compile目标用来编译位于src/main/java/文件夹下的主源代码.testCompile目标用来编译位于src/test/java/文件夹下的測试源代码. 用户能够通过两种方式

Maven传递依赖的时候,同名包不同版本的包均会下载,但是编译的时候,只会加载一个高版本的。

描述,在一个Maven项目中,同时依赖了spring-tomcat-weaver  和  struts-core 包,但是spring-tomcat-weaver 需要commons-digester-1.2 struts-core 需要commons-digester-1.8 Pom文件如下: <dependencies> <dependency> <!-- 需要commons-digester-1.2包 --> <groupId>org.springfr