Maven
4.5 依赖管理
- 基本概念
当A jar包需要用到B jar包中的类时,我们就说A对B有依赖。例如:commons-fileupload-1.3.jar依赖于commons-io-2.0.1.jar。
通过第二个Maven工程我们已经看到,当前工程会到本地仓库中根据坐标查找它所依赖的jar包。
配置的基本形式是使用dependency标签指定目标jar包的坐标。例如:
<dependencies> <dependency> <!—坐标 --> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.10</version> <!-- 依赖的范围 --> <scope>test</scope> </dependency> </dependencies> |
- 直接依赖和间接依赖
如果A依赖B,B依赖C,那么A→B和B→C都是直接依赖,而A→C是间接依赖。
4.5.1 依赖的范围
- compile
[1]main目录下的Java代码可以访问这个范围的依赖
[2]test目录下的Java代码可以访问这个范围的依赖
[3]部署到Tomcat服务器上运行时要放在WEB-INF的lib目录下
例如:对Hello的依赖。主程序、测试程序和服务器运行时都需要用到。
- test
[1]main目录下的Java代码不能访问这个范围的依赖
[2]test目录下的Java代码可以访问这个范围的依赖
[3]部署到Tomcat服务器上运行时不会放在WEB-INF的lib目录下
例如:对junit的依赖。仅仅是测试程序部分需要。
- provided
[1]main目录下的Java代码可以访问这个范围的依赖
[2]test目录下的Java代码可以访问这个范围的依赖
[3]部署到Tomcat服务器上运行时不会放在WEB-INF的lib目录下
例如:servlet-api在服务器上运行时,Servlet容器会提供相关API,所以部署的时候不需要。
- 其他:runtime、import、system等。
各个依赖范围的作用可以概括为下图:
4.5.2 依赖的传递性
当存在间接依赖的情况时,主工程对间接依赖的jar可以访问吗?这要看间接依赖的jar包引入时的依赖范围——只有依赖范围为compile时可以访问。例如:
Maven工程 |
依赖范围 |
对A的可见性 |
||
A |
B |
C |
compile |
√ |
D |
test |
× |
||
E |
provided |
× |