maven的scope作用域以及依赖传递

maven的dependency标签除了针对jar包的定位gav外，有时候还会写上scope这个标签，它表示该jar包的作用范围，可用值如下：

compile：默认的scope的值，对src/main/java有效，对src/test/java也有效，参与打包，这也是大多数jar包的配置

test:对src/main/java无效，对src/test/java下面的类有效，不参与打包，比如我们最常用的junit的配置：

<!-- https://mvnrepository.com/artifact/junit/junit -->
<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.12</version>
    <scope>test</scope>
</dependency>

provider：对主程序有效，对测试程序有效，配置了这个作用域范围的jar包，说明在编译和测试时候需要使用到这个jar，打包时不需要，比如常用的servlet-api,因为我们的maven工程一般使用jetty或者tomcat插件来启动，在工程里面假如用到了HttpServletRequest这个类，很常见吧，但是我们的maven工程并没有像dynamic web project那样，引入了tomcat的jar包，因此我们需要引入:

<dependency>  
            <groupId>javax.servlet</groupId>  
            <artifactId>servlet-api</artifactId>  
            <version>2.3</version>
            <scope>provided</scope>  
        </dependency>

打成war包的时候，肯定会把war包放到web容器里面，而web容器里面已经存在了servlet-api,因此我们在打成war包的时候就需要把servlet-api给排除掉，因此使用provided的scope级别。

runtime:程序运行时才需要真正使用到的jar包，比如mysql-connector-java.jar

	<dependency>
		    <groupId>mysql</groupId>
		    <artifactId>mysql-connector-java</artifactId>
		    <version>5.1.6</version> 
		    <scope>runtime</scope>  
		</dependency>

------------------------------------------------------------依赖传递规则------------------------------------------------------------------------

maven针对groupid和artifactId相同，version不同的jar包，处理依赖传递依从两个规则：

1. 如果级别相同，就使用最先声明的版本，即最先声明原则

2. 如果级别不同，就用级数最少的那个jar版本，即最短路径原则

举个例子,现在有如下的依赖关系：

    a-->log4j-1.3--〉common-log.1.1:直接依赖

    b-->log4j-1.4

    b-->common-log.2

    c-->a.jar,b.jar

那么c最终使用的是哪个版本的log4j，哪个版本的common-log呢？根据上边的两条规则，

log4j使用的是log4j-1.3(同级取先/最先声明),common-log使用的是common-log.2（不同级就用级数最少的那个jar版本/最短路径）。

另外需要注意的是，test级别的jar包是不参与传递的。