Maven中jar的依赖关系详解

上一篇博文讲了maven的安装和dos命令方式的使用。但却没有叙述maven的最大的特点：

1. jar之间的依赖引入
2. 项目拆分合并

本篇博文结合实际操作讲述jar的依赖关系。

一.依赖的范围（有效性）

要详细理解依赖关系首先得明确依赖的范围。依赖范围有3种:compile test  provided

 

	compile	test	provided
编译	√	×	√
测试	√	√	√
部署（运行）	√	×	×

1. compile是全局的，只要gav配置了compile那么编译、测试、部署（运行）都能获取该jar,也可以理解为使用
2. test 则只能再测试命令执行时获取该jar
3. provided则只能再编译、测试时使用

那么在哪里配置依赖范围？

我们在maven工程的核心——pom.xml中配置.<scope>标签之间就是依赖范围，可以不配，默认是compile

二.依赖传递及依赖原则（重点）

首先我们要明白: 例如A.jar ->B.jar 当我们通过maven引入A.jar时,会自动引入B.jar。那么如果A.jar->B.jar->C.jar,那么maven会不会在引入A.jar时自动引入C.jar（B.jar肯定时引入的...）？答案是可以的但是有限制条件---要使 A.jar ->C.jar :当且仅当 B.jar 依赖于C.jar的范围是compile。为了测试我们先写2个maven工程，并把其中一个install至本地仓库，然后用另一个工程引入这个jar（拆分合并暂不叙述）。

下面是2个工程的pom.xml文件,第一个是即将被引入的maven工程的pom.xml

d

下面则是另外一个：

那么当我们执行第二个maven工程时则自动会引入junit包，如下所示

当我们把第一个pom.xml的<scope>配置为test或provided时则第二个maven工程不会自动引入junit。

 

 

依赖原则（为了防止冲突）：

• 路径最短优先原则。要知道不同开发人员可能会引入不同版本的jar，甚至你在实际开发时也有可能反复引入不同版本的jar。那么maven到底引入哪个版本的jar呢？maven按照路径最短引入jar。上图解释。那么最后引入的版本就是本项目pom.xml配置的junit3.8，而4.0则被忽略。
• 路径长度相同时：
  • 在同一个pom.xml文件中有2个相同的依赖（覆盖）：后面声明的依赖 会覆盖前面声明的依赖 （严禁使用本情况，严禁在同一个pom中声明2个版本不同的依赖）
  • 如果是不同的 pom.xml中有2个相同的依赖（优先）：则先声明的依赖 ，会覆盖后声明的依赖.上图解释。声明的顺序则是在pom.xml中配置依赖的顺序。这和第一点是相反的，一定要注意。