转】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>
<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.若两个依赖包处于依赖树上的同一层,则谁在前选择谁。

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

时间: 11-05

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

Maven实战七

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

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

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

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

Maven实战07_依赖

1:依赖声明 <project> ... <dependencies> <dependency> <groupId>...</groupId> <artifactId>...</artifactId> <version>...</version> <type>...</type> <scope>...</scope> <optional>.

[Maven实战](8)依赖配置与依赖范围

 1. 依赖配置 依赖基本配置: <project> <dependencies> <dependency> <groupId>...</groupId> <artifactId>...</artifactId> <version>...</version> <exclusions> <exclusion> <groupId>...</groupId>

Gradle实战教程之依赖管理

这是从我个人网站中复制过来的,原文地址:http://coolshell.info/blog/2015/05/gradle-dependency-management.html,转载请注明出处. 简要概述依赖管理 不算完美的依赖管理技术 自动管理依赖的重要性 自动依赖管理面临的挑战 声明依赖 外部模块依赖 文件依赖 配置远程仓库 这一章我将介绍Gradle对依赖管理的强大支持,学习依赖分组和定位不同类型仓库.依赖管理看起来很容易,但是当出现依赖解析冲突时就会很棘手,复杂的依赖关系可能导致构建中依

Maven实战之初识MavenMaven的简单介绍

Maven实战之初识MavenMaven的简单介绍 作用:Maven主要用于项目的构建,管理项目的依赖以及项目的信息(自动化构建.编译.单元测试.生成文档.打包.部署) 优势:相对于Ant.Make等,Maven抽象构建过程,提供构建任务的实现,自动化构建,有效地提高了开发效率,使开发人员可以集中精力在主要的开发任务上.而且Maven是跨平台工具,意味着在主流操作系统中,Maven都提供了对应的技术支持 使用注意:需要在JDK1.4及以上版本使用 Maven的安装下载地址:Maven下载地址,选

Maven(2)-坐标和依赖

本文简要介绍Maven里面的坐标(coodinate)以及maven依赖管理(Dependency) 一.坐标 先来个截图: 在上图peoject栏目有groupId,artifactId,version,这个就是maven中坐标的概念,这三个属性能够唯一定位一个java架包,其中: groupId代表架包所在的组织(package的概念),比如com.cnblogs artifactId是一个单独架包(项目)的唯一表示 version代表当前项目的版本号 另外坐标还有个packaging属性,

Maven实战:Maven生命周期

前言 之前有写过一篇文章Maven实战,介绍了Maven的一些基本概念,以及对于一个初学者而言的Maven基础知识,当时在我看来掌握了这些基本是够用的. 随着工作的深入,越来越感觉对于Maven的理解不够,很多时候使用Maven出了问题都无法很快地解决,因此打算深入地从搭建Maven工程开始学习一下Maven,这篇文章就将自己的学习历程记录下来和网友朋友们分享. 从搭建最简单的Maven项目开始 LZ使用的是MyEclipse,那么就是用MyEclipse搭建一个简单的Maven项目.第一步,n