昨天说道在eclipse中创建简单的maven项目,今天来唠唠包的依赖范围和依赖的传递。
一、包的依赖范围
<dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.10</version> <scope>test</scope> </dependency>
我们在添加一个JAR包的时候,dependency标签中会有一个scope标签,这个标签中的值表示的就是这个JAR包的依赖范围,有6个可以填的值,分别是:compile、provided、runtime、test、system、import,它们各自的依赖范围分别是:
1.compile是默认的依赖范围,表示在编译或者打包时候都需要的JAR包。
2.provided表示只有在编译或者测试的时候需要,打包的时候是不需要的,例如servlet-api.jar,在tomcat的lib包中本就存在了,如果再在项目中打包一个,那么在tomcat上发布项目的时候势必会出现重复、冲突。
3.runtime 顾名思义就是运行时需要的JAR包了,例如数据库的链接包,如果不跟数据库打交道根本就不需要,所以这个在编译是不需要的。
4.test 这个更好理解了,测试的时候才需要的JAR包,例如junit、dbunit,都是测试的时候需要的,打包和编译的时候不需要。
5.system
system范围依赖与provided 类似,但是你必须显式的提供一个对于本地系统中JAR 文件的路径。这么做是为了允许基于本地对象编译,而这些对象是系统类库的一部分。这样的构件应该是一直可用的,Maven 也不会在仓库中去寻找它。如果你将一个依赖范围设置成系统范围,你必须同时提供一个 systemPath 元素。注意该范围是不推荐使用的(你应该一直尽量去从公共或定制的 Maven 仓库中引用依赖)
至于import,我还不知道到底该怎么用,就不误导大家了,如果有人知道,还请不吝赐教。
二.依赖传递
依赖范围说完了,下面说说依赖的传递,在maven项目中,依赖是可以传递的,但是也不是什么依赖都可以传递,如果依赖范围是test,那么肯定不可以传递,其实可以传递的也就是compile罢了。
1.同级别传递
什么叫同级别传递呢?比如现在有现在有项目A依赖于某个JAR包,假设是J1.0,同时有项目B依赖于J2.0,项目C同时依赖于项目A和B,那么项目A和B都是直接依赖于名字是J的JAR包,项目属于间接依赖于名字为J的JAR包,此时A和B就属于同级别的。那么此时项目C中的JAR包的版本是哪个呢?
结论:同级别的传递,先声明哪个,传递的就是哪个。
什么意思呢?意思就是如果在C项目中先声明了A项目,那么C项目中依赖的就是J1.0,如果在C项目中先声明的是B项目,那么C项目依赖的就是J2.0.举个例子来说吧,下面看图:
现在有项目TestA,依赖的commons-logging-1.2.jar
项目TestB,依赖的commons-logging-1.1.jar
项目TestC同时依赖于TestA和TestB,并且先声明了A
那么C中commons-logging的版本会是哪个呢?
很明显的是1.2版本,也就是A项目依赖的版本,反之,如果再C中先声明了B,那么C中依赖的肯定就是1.1版本了。
2.不同级别的传递
还是上面的三个项目作为例子,上面项目B的图片可以看到项目B依赖了log4j-1.2.12.jar,但是在项目B的pom.
通过项目B的依赖关系图可以看到这个包是依赖于commons-logging 1.1.jar的,也就是项目B对于log4j是间接依赖。
下面我在项目C中加入了log4j的另一个版本。
项目C直接依赖于log4j 1.2.6.jar,同时C------->B--------->log4j 1.2.12.jar,那么在C中的log4j是哪个版本呢?
可以看到C依赖的是1.2.6版本的,也就是依赖层次短的。
结论:依赖级别不同的时候,依赖于层次最短的。
3.排除依赖
如果你不想使用某个人传递过来的jar包,那么你可以将这个版本排除掉,方法如下:
Ok!今天就这样咯!!!
原标题:maven学习(四)
关键词:maven