Maven -- 依赖体系

今天遇到个问题，如下
A项目依赖B.jar，B.jar依赖common.jar版本号0.0.1
A项目依赖C.jar，C.jar依赖common.jar版本号0.0.2
这里引入了maven的一个间接依赖的概念，A间接依赖common.jar，但是版本号是如何选择的，不清楚，看下面的博文我们来讲解

内容摘自http://www.cnblogs.com/WJ5888/p/4348506.html

直接依赖/间接依赖

Maven中最容易理解的就是直接依赖,A项目的运行需要有B项目的存在，这就是一个直接依赖，当B项目的运行需要有C项目的存在时，这里就存在A项目对C项目的一个间接依赖,A项目要想成功运行，在其类路径下必须要存在B项目和C项目，当然使用Maven我们不需要关注这种间接依赖，Maven会帮我们处理,如我们的项目中需要spring-core，在Pom文件中我们只需要添加如下配置，再看看我们的类路径是不是存在了spring-core-4.1.4.RELEASE.jar/commons-logging-1.2.jar两个Jar包,其中这个commons-logging-1.2.jar包就是通过间接依赖加入类路径下的~

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-core</artifactId>
    <version>4.1.4.RELEASE</version>
</dependency>

再看看spring-core-4.1.4.RELEASE.jar里面的Pom文件，在这个Pom文件中将对commons-logging-1.2.jar依赖设置为Compile并且非可选,下是是其Pom.xml文件

<dependency>
  <groupId>commons-codec</groupId>
  <artifactId>commons-codec</artifactId>
  <version>1.10</version>
  <scope>compile</scope>
  <optional>true</optional>
</dependency>
<dependency>
  <groupId>commons-logging</groupId>
  <artifactId>commons-logging</artifactId>
  <version>1.2</version>
  <scope>compile</scope>
</dependency>
<dependency>
  <groupId>log4j</groupId>
  <artifactId>log4j</artifactId>
  <version>1.2.17</version>
  <scope>compile</scope>
  <optional>true</optional>
</dependency>
<dependency>
  <groupId>net.sf.jopt-simple</groupId>
  <artifactId>jopt-simple</artifactId>
  <version>4.8</version>
  <scope>compile</scope>
  <optional>true</optional>
</dependency>
<dependency>
  <groupId>org.aspectj</groupId>
  <artifactId>aspectjweaver</artifactId>
  <version>1.8.4</version>
  <scope>compile</scope>
  <optional>true</optional>
</dependency>

在这个Pom.xml文件中,只有这个Jar包是必须的，其他依赖均是可选的(Optional)依赖,在Maven中可选依赖是不会进行传递的,为什么要有可选依赖呢？例如，一个持久层模块不但可以持久化Oracle数据库，也可以持久化Mysql数据库，那么在这个持化层框架中应该对应了两份代码，一份是关于Oracle持久化的处理，一份是关于Mysql持久化的处理，如果将持久层模块的Oracle与Mysql驱动均设置为非可选依赖，那么依赖这个持久层框架的项目类路径中将同时出现Mysql以及Oracle的驱动Jar包，如果真的这样，你会不会感觉到这种设计很奇葩~,因此Maven中Optional关键字就诞生了~~~

重复引入的处理?（间接依赖版本号如何选择）

在什么情况下，会出现依赖的重复引入呢?

场景一：项目A依赖于项目B与项目C,项目B与项目C均依赖于项目D,这时项目中就会出现两份D项目(有可能B项目与C项目依赖的D项目的版本还不一样~),这种情况下,Maven是如何处理的呢?

规则，第一声明者优化

这种情况下，Maven处理方法，是完全依赖于项目B与项目C在Pom.xml文件中声明的顺序，哪个声明在前就使用哪个项目的D依赖,如下是一个典型的例子~

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-core</artifactId>
    <version>4.1.4.RELEASE</version>
</dependency>
<dependency>
  <groupId>org.apache.hbase</groupId>
  <artifactId>hbase-common</artifactId>
  <version>0.99.0</version>
</dependency>

场景二：一个Pom文件中声明了对一个项目的高低版本的依赖

规则,使用最后声明者,示例如下

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-core</artifactId>
    <!-- 版本一 -->
    <version>2.0.6</version>
</dependency>
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-core</artifactId>
    <!-- 版本二 -->
    <version>4.1.4.RELEASE</version>
</dependency>

最终spring-core-4.1.4.RELEASE.jar的版本号为4.1.4,但当将版本一与版本二的顺序调换后，则项目类路径下依赖的Jar包就会变成2.0.6

场景三:A项目依赖于B项目，B项目依赖于D项目，A项目依赖于C项目，C项目依赖于E项目，E项目又依赖于D项目，简化一下，即A->B->D/A->C->E->D,这时项目中也会由于传递依赖，引入了对D项目的两次依赖

规则:最短路径优先

在场景三中，由于A项目从B项目得到对D项目的依赖路径要比从C项目中获取D项目依赖的路径要短，说起来太转口了~,因此会优先采用从B项目中得到的D依赖,如下是一个示例~