Maven 依赖范围及依赖原则

1.依赖范围

想必大家在maven的pom.xml文件中 定义依赖 除了 groupId ,artifactId,version三个必要的标签外，还见过 另外一个标签scope(如下)。没错这个标签就是我下面要说的依赖范围。

 
    
        junit
        junit
        4.12
        test
    

其实maven中的依赖范围有很多种，但是我们常用的只有以下三种，我们掌握这三种就够用了。他们分别是 compile (编译)范围依赖，test(测试)依赖，provided依赖。那问题来了我们在定义依赖的时候 这个scope 该怎么填呢？我们先讲一下判定规则：

• 是否对main主程序有效

• 是否对test测试程序有效

• 是否参与打包

• 是否参与部署
  其实可以把这三个依赖分为两种情况

• 针对程序结构(分主程序和测试程序)的依赖
  我们在前面就讲过 maven project 遵循着一定目录结构
  
  complie 编译范围的依赖 (典型例子 spring-core 对main和test都有效，参与打包参与部署)

  org.springframework
   spring-core
   4.2.6.RELEASE

test 测试范围的依赖 (典型例子junit 只对test有效，不参与打包参与部署)

	junit
	junit
	4.12
	test

• 针对开发过程的依赖
  provided 范围的依赖(典型例子servlet-api 在开发过程中必须提供(添加tomcat运行时环境/添加maven依赖)，打包过程中忽略，运行时有servlet容器提供)

    org.apache.tomcat
    servlet-api
    6.0.32

2.依赖传递

为了证明依赖会传递我分别建了一个A模块 依赖junit 和spring-core;B模块依赖junit和A模块如下：


我们用idea的依赖树来看下 A模块，B模块这两个模块的依赖关系树：
先是A模块的 dependency tree

再是B模块的关系树 dependcy tree

从B的pom.xml 代码中，我们可以看出 B模块在pom.xml文件中并没有直接的配置Spring-core的依赖，但是从B的依赖关系树种我们可以看出B也依赖了spring-core，只是这个依赖关系是因为 A依赖了spring-core ，而B又依赖了A所以 B也间接的依赖了spring-core因此可以得出一个结论：
依赖可以相互之间传递

3.依赖排除

在某些情况下我们可能需要依赖某个a.jar,但又不想间接依赖这个a.jar所依赖的jar包，这时我们可以采用exclusion 来排除某个依赖。 如下：

  org.springframework
    spring-core
    4.2.6.RELEASE
    
        
            commons-logging
            commons-logging
        
    

4.依赖原则

我们在工作中的项目都是分模块的，而且模块之间又互相依赖，这个时候我们可能会引入相同的依赖 ，这时maven取那个依赖呢？这就是maven依赖的原则：

• 路径不同间接依赖中maven采用的是路径最短者优先
• 路径相同间接依赖中maven 采用的是依赖定义顺序从上到下
  我们可以通过以下来验证这两个依赖原则的正确性，定义一个A模块分别依赖junit 与spring-core-4.2.7; 定义一个B模块 依赖与junit与A模块 与spring-core-4.3.7；定义一个C模块分别依赖junit与B;定义一个D模块 分别依赖A模块与C模块。然后根据
  C模块与D模块最后依赖的spring-core的版本来验证上述两个依赖原则。
  A模块
  
  B模块
  
  C模块
  
  根据C模块的依赖关系树 如下
  

D模块则分两种情况：
1.B模块先定义与

    
        com.javxuam.maven
        B
        1.0-SNAPSHOT
    

    
        com.javxuam.maven
        A
        1.0-SNAPSHOT
    

A依赖定义优先B依赖

   
        com.javxuam.maven
        A
        1.0-SNAPSHOT
    

    
        com.javxuam.maven
        B
        1.0-SNAPSHOT