依赖是Maven 中最关键的部分我们之所以在工程中使用Maven就是因为它的依赖管理功能。如果我们想要在工程中引入某个jar 包只需要在pom.xml 中引入其jar 包的坐标即可。比如引入log4j 的依赖
<dependencies> <dependency> <groupId>log4j</groupId> <artifactId>log4j</artifactId> <version>1.2.17</version> <scope>compile</scope> </dependency> </dependencies>Maven 通过groupId、artifactId与version三个向量来定位Maven 仓库其jar 包所在的位置并把对应的jar 包引入到工程中来。
二、依赖范围在引入log4j 依赖的时候有一个scope设置这个scope设置的值就是对应的依赖范围(因为compile 是默认的依赖范围所以有时也可以省略)。
Maven 提供了六种依赖的范围compile、test、provided、runtime、system 和import。其中compile 是默认的依赖范围。这里主要对比前三种常用的依赖范围。
type
对主程序是否有效
对测试程序是否有效
是否参与打包与部署
典型例子
compile
Y
Y
Y
log4j
test
N
Y
N
junit
provided
Y
Y
N
servlet-api
需要注意的是provided 范围依赖是不参与项目打包与部署的比如 servlet-api如果你把scope改成compile 范围的依赖就会因为jar 包冲突报错。原因是我们在启动web 项目时tomcat 已经在启动时加载了自身的 servlet-api。
依赖的传递性是指在A 中添加对B 的依赖在B 中添加对C 的依赖如果依赖范围是compile 的A 不仅会有B 的jar 包也会有C 的jar 包。如果在C 中添加了某个依赖那么根据传递性A 和B 也可以使用A 添加的依赖而不需要自己再重新引入依赖。
最短路径优先原则如果A 依赖于BB 依赖于C在B 和C 中同时有log4j 的依赖并且这两个版本不一致那么A 会根据最短路径原则在A 中会传递过来B 的log4j版本。
路径相同先声明原则如果在A 同时依赖于B 和CB 和C 没有依赖关系并且都有log4j 的依赖且版本不一致那么A 会引入在pom.xml 中先声明依赖的log4j 版本。
我们在当前工程中引入了A 的依赖而A 同时有对B 的依赖根据传递性我们知道在当前工程中会自动引入对B 的依赖。其中B 可能是一个不稳定的版本或者对当前的工程存在着不良的影响 。这时我们就可以在引入对A 依赖的同时排除对B 的依赖。
下面我们以spriing-core 为例当我们在pom.xml中引入对spriing-core 的同时会自动将commons-logging 的jar 包引入进来。如下所示
假设这个commons-logging 是一个不稳定的版本(只是假设)我们希望在引入spriing-core 时排除commons-logging。这时我们可以使用exclusion来进行排除。
在使用Maven 时可能我们只是简单知道Maven 的用法从而忽略了其中的一些细节。希望这篇博文能够为初步了解Maven 或只会简单使用Maven 的人提供帮助。