MAVEN的依赖

1.依赖范围

在maven工程中，我们可以在pom.xml文件中通过配置来管理我们的依赖包

<dependency>

<groupId>mysql</groupId>

<artifactId>mysql-connector-java</artifactId>

<version>${mysql.version}</version>

</dependency>

实际上，如上的配置还隐藏着一个熟悉描述： <scope>compile</scope>。

<scope></scope>在maven中用于定义包依赖关系，有如下四个value:

1).compile 默认的依赖范围，将依赖在编译和打包的时候加进去；

2).provided 会在编译和测试的时候把这个包加进去，在打包的时候不会加进去。如servlet-api；

3).runtime 在运行的时候依赖，在编译的时候不依赖。如mysql-connector-java；

4).test 测试范围有效，在编译和打包时都不会使用这个依赖。比如junit、dbunit。

2.依赖传递

如果用maven建立了两个工程A、B，在工程A中通过pom.xml配置文件依赖了包p1。那么如果工程B依赖了A，B就会继承依赖包p1。但是如果A依赖包p1时，依赖范围是test那么，B就不会依赖p1。因为test范围的包是不会进行依赖传递的。

3.依赖层次

有三个maven工程A、B、C，依赖关系如下：

A依赖p1-1.0,p2

B依赖p1-1.1,p3

C依赖A、B

在工程A和B中都依赖了p1，而p1的版本又不同，那么C依赖那个版本的p1呢？这里遵循声明优先原则，如果C的pom.xml配置文件声明如下：

<dependency>

<groupId>A</groupId>

......

</dependency>

<dependency>

<groupId>B</groupId>

......

</dependency>

那么C就依赖p1-1.0，反之则依赖p1-1.1。

还有一个原则是依赖最短路径优先，比如A，B，C三个工程依赖关系如下：

A依赖p0->p1-1.0,p2

B依赖p1-1.1,p3

C依赖A、B

这里工程A没有直接依赖p1-1.0，而是依赖p0再间接依赖p1-1.0。那么如果在C的pom.xml文件中还是如上的声明，C就不会再依赖p1-1.0而是依赖p1-1.1。因为B对p1的依赖是直接依赖，也就是依赖路径最短，因此C会依赖p1-1.1。