【Maven由浅入深】6.maven的依赖特性

之前我们做了3个模块，user-core、user-log和user-service，之间展现出了相互依赖的特性。

接下来我们要说依赖中几个比较重要的概念。
有没有发现我们的pom文件的<dependency></dependency>标签对可以设置一个<scope></scope>标签对，然后其中的值有compile、import、provided、runtime、system、test。
system和import我们先不说。说一下compile、provided、runtime和test。

compile:
我们的依赖范围是基于compile的依赖范围，也是我们的默认依赖范围。当<scope></scope>标签对中是compile时，它会在编译或打包的时候把依赖加进去，这就是compile的范围。

provided:
当我们编译、测试的时候会把依赖加进去，但是当我们打包的时候就不会把依赖加进去。(例如我们做Web需要Servlet-api.jar，但是我们的tomcat的lib中是有这个包的，我们最后给项目打包的时候如果把Servlet-api.jar依赖也加进去的话，就会发生冲突。)

runtime:
在运行的时候依赖，在编译的时候不依赖。

test:
在测试范围内依赖有效，在编译和打包的时候不会使用这个依赖。(例如我们使用的测试jar包junit，在项目正式启动后这个包就不需要了，所以我们仅在测试中使用这个依赖，编译和打包的时候就不需要了，即节省了编译压力提高了效率)

注意，如果我们将junit的scope设置成test，我们编译的时候只为test源文件夹下的类提供junit依赖，src下其它文件夹下的类不提供依赖，所以我们要注意，scope为test的依赖只能提供给test文件夹下的类，编写的时候注意使用范围。

我们注意到，我们的user-service模块集成了user-core和user-log两个模块，而且引用了后两者的依赖包，我们要注意，这里集成的依赖包是后两者编译compile范围内的依赖包，而不是所有的依赖包(scope不是默认的或不是compile)。

接来下我们来谈一下依赖里让人比较头疼的一些事。
假设我们有一个A项目，依赖了一个L-1.0.jar，然后我们有一个B项目，依赖了一个L-2.0.jar，然后我们又有一个C项目，及依赖于A，又依赖于B:
A--L1.0
B--L2.0
C--A,B
那么C项目是引用的L-1.0.jar呢，还是引用L-2.0.jar呢？我们来试验一下:

我们的user-core依赖的log4j版本是1.2.17:

我们的user-log依赖的log4j版本是1.2.9:

那集成这两个项目的user-service，使用的log4j是什么版本的？
我们看一下:

为什么？我们看一下user-service的pom文件：
发现我们是先引入的user-log，后引入的user-core：

所以先引入了log4j-1.2.9，然后引入user-core的时候发现已经存在log4j的jar，所以就没有重复引入。
所以ABC之间，A、B和L的依赖是直接依赖，C和L的依赖是间接依赖。当我们有了间接依赖之后，先声明了哪个使用该依赖的模块，就间接使用哪个依赖。

接下来看下一点：
如果级别相同，哪一个先写依赖哪一个，那么我们看一下这个情况:
我们现在将user-log和user-core的依赖先后调换一下:

首先看我们的log4j，使用的就是1.2.17了:

这一点是没有问题的，但是看我们的common-logging版本:

是1.1.1对吧？回来看一下我们user-core和user-log的common-logging版本: