上一篇博文讲了maven的安装和dos命令方式的使用。但却没有叙述maven的最大的特点:
- jar之间的依赖引入
- 项目拆分合并
本篇博文结合实际操作讲述jar的依赖关系。
一.依赖的范围(有效性)
要详细理解依赖关系首先得明确依赖的范围。依赖范围有3种:compile test provided
| compile | test | provided |
编译 | √ | × | √ |
测试 | √ | √ | √ |
部署(运行) | √ | × | × |
- compile是全局的,只要gav配置了compile那么编译、测试、部署(运行)都能获取该jar,也可以理解为使用
- test 则只能再测试命令执行时获取该jar
- 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中配置依赖的顺序。这和第一点是相反的,一定要注意。