MAVEN依赖

MAVEN依赖

本文内容摘自《Maven实战》

每个dependencies都可以包含一个或多个dependency元素,用来声明一个或多个项目依赖，每个依赖包含的元素有:

• groupId,artifactId,version :基本坐标
• type:依赖类型，默认为jar
• scope:依赖的范围
• optional:标记依赖是否可选
• exclusions:排除传递性依赖

依赖范围

MAVEN在编译，测试，运行的时候会使用不同的classpath,这也就产生的所谓的依赖范围,依赖范围就是用来控制和依赖和classpath的关系。

MAVEN的依赖范围包含以下几种:

• compile 编译时依赖，默认使用该依赖，此范围下对编译，测试，运行都有效。
• test 测试时依赖，例如Junit
• provided 已提供依赖范围,对于编译和测试有效，运行时无效，例如servlet-api
• runtime 运行时依赖，测试和运行时有效，编译主代码时无效,例如jdbc驱动
• system 系统依赖范围，范围与provided一致,但是需要通过systemPath显示的指定依赖文件的路径，MAVEN仓库无法解析，与系统绑定，构建时不可移植，谨慎使用！
• import 导入依赖范围，不会对三种classpath产生实质影响

|scope|编译|测试|运行|例子|
|-----|:--------😐:---------😐--------😐
|compile|Y|Y|Y|spring-core|
|test|—|Y|—|JUnit
|provided|Y|Y|—|servlet-api|
|runtime|—|Y|Y|JDBC驱动实现
|system|Y|Y|—|本地但不包含在MAVEN仓库中的类库文件|

传递性依赖

MAVEN的传递性依赖机制在帮我们解决依赖问题的同时也帮助我们解决了相关的传递依赖问题。

)

传递性依赖和依赖范围

假设:A依赖于B,B依赖于C,那么A对于B是第一直接依赖,B对于C是第二直接依赖,A对于C是传递性依赖，第一直接依赖的范围和第二直接依赖的范围直接决定了传递性依赖的范围。
如下图所示:
最左边一列为第一直接依赖范围,最上面一列表示第二直接依赖范围

	compile	test	provided	runtime
compile	compile	—	—	runtime
test	test	—	—	test
provided	provided	—	provided	provided
runtime	runtime	—	—	runtime

依赖调解

MAVEN的传递性依赖机制，简化和方便了依赖声明，使我们只需要关心直接依赖，但是当传递性依赖造成问题的时候，我们就需要知道该传递性依赖是由哪条依赖路径引起的。
例如:
项目A有如下依赖关系:
A-->B-->C--X(1.0)
A-->D-->X(2.0)
X作为A的传递性依赖,两条路径对应两个不同版本的X,MAVEN为了避免依赖重复,MAVEN会选择其中一个进行解析,那么此时就涉及到MAVEN的依赖调解。MAVEN的依赖调解原则如下:

第一原则:路径最近者有限。
第二原则:第一声明者优先。

MAVEN默认执行第一原则，当路径相同时执行第二原则。

博客园地址--夙笺