你的位置:首页 > Java教程

[Java教程]maven学习(四)


  昨天说道在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!今天就这样咯!!!