Maven的依赖管理(Dependency Management)

Maven的亮点之一就是依赖管理，其介绍依赖管理的产品文档竟然长达15页之多，可能这个概念的复杂度不是很小，值得关注，值得学习。

以下是一个POM中典型的一段关于依赖的片段：

<project xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                      http://maven.apache.org/xsd/maven-4.0.0.xsd">
  ...
  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.0</version>
      <type>jar</type>
      <scope>test</scope>
      <optional>true</optional>
    </dependency>
    ...
  </dependencies>
  ...
</project>

1、Transitive Dependency (传递依赖)

    你的项目依赖于A，A又依赖于B。你的项目是否要声明你依赖于B？ Maven的回答是它帮你自动管理这种依赖的传递，你不需要声明你依赖于B，由Maven来做。

    不难就会想到一种冲突的情况，如A -> B -> C -> D 2.0，同时存在A -> E -> D 1.0，那么应该使用D1.0还是D2.0呢？用Maven的话来说，这件事情叫做“Dependency Mediation”（依赖仲裁），当出现这种冲突时，采用“Nearest Definition”的解决办法，即采用最短路径，在上述例子中仲裁的结果是D1.0，因为它的路径更短。如果两个路径长短是一样的呢？那么只能是谁先出现就选谁了。上述例子中如果你显式声明A依赖于D2.0，那么Maven就会帮你选取D2.0而不是D1.0。

 

2、Dependency Scope （依赖范围）

    举例来说，你开发时需要做测试，你需要依赖于junit的jar，但是部署应用时并不需要它，因为单元测试不会在生产环境上跑，也就是说最终打包的jar或者war不包含junit的jar。又如你开发web程序，你的servlet/jsp进行编译需要依赖于servlet-jsp的标准api（J2EE的jar），但是部署时也是不需要它的，因为你的应用服务器肯定有这些东西。

    因此，Maven考虑了6中可能的scope供选择：

    - compile: 默认的scope。编译、测试、打包全都需要。compile参与依赖传递，就是说，你的项目A依赖于B(依赖scope是compile)，项目C依赖于你的项目A，那么C也就依赖于B。

    - provided: 表示JDK或者容器会在Runtime时提供这些(jar)，如上面说到的servlet api。provided的东西在编译和测试时会用到，不参与传递依赖。

    - runtime: 表示编译时不需要，但测试和运行时需要，最终打包时会包含进去。

    - test: 只用于测试阶段（测试的编译和测试的运行），典型的就是junit的jar。

    - system: 和provided类似，但要求jar是你的系统里已有的，不会在repository里找，如rt.jar,tools.jar这些。

    - import: 简单的说，你的项目的pom可以继承另一个项目的pom，从而继承了父项目的依赖关系，但是因为之后single inheritance的限制，所以创造了import，使得你可以“导入”或者说“继承”任何一到多个项目的依赖关系。

    如果你要考虑更细一些，你的项目依赖于A（scope1），A依赖于B（scope2），那么你的项目对B的依赖应该算是哪个scope呢？官方文档上有个表格，列举了scope1和scope2的一个矩阵关系（各自都可能是compile/provided/runtime/test），然后最后结果应该是什么。

 

3、Dependency Classier

    用于再次区分不同类别的东西，如在jdk1.4下编译的东西还是jdk1.5下出来的云云。

 

还有很多东西，有时间再接着写吧。