依赖：

1.当 A jar 包用到了 B jar 包中的某些类时，A 就对 B 产生了依赖，这是概念上的描述。那么如何在项目
中以依赖的方式引入一个我们需要的 jar 包呢？使用 dependency 标签指定被依赖 jar 包的坐标就可以了。

2.Maven解析依赖信息时，会到本地仓库中查找被依赖的jar包。（如果未找到第三方jar包，将会自动联网下载。对于我们自己开发的Maven工程，使用Install命令安装后就可以进入仓库）

3.依赖的范围：

4.依赖的传递性：A依赖B，B依赖C，A能否使用C呢？那要看B依赖C的范围是否是compile,如果是则可用，否则不可用。

a.可以传递的依赖不必在每个工程中都重复声明，在“最下面”的工程中依赖一次即可。

b.非compile范围的依赖不能传递，所以在各个工程模块中，如果有需要就得重复声明。如servlrt-api。

5.依赖的排除：如果我们在当前工程中引入了一个依赖是A，而A有依赖了B，那么Maven会自动将A依赖的B一如当前工程，但是个别情况下，B有可能是个不稳定版本，或对当前的工程有不良的影响。这时我们可以在引入A的时候将B进行排除。

比如：排除spring中log4j的依赖：

配置方式：

注：排除版本号的查询：a.点击“Dependency Hierarchy”

                                        b.选中所要查询的jar包，点击“Open DOM”，出现了所有的坐标信息。

       （在哪个工程中排除依赖，哪个工程中就没有了。相互依赖的工程，排除上面的，下面的有，排除下面的，上面的没有） 

6.依赖的原则：

（1）作用：解决模块之间的jar包冲突问题

（2）a.路径最短者优先原则

         b.路径相同时，先声明者优先。（先声明指的是dependency标签的声明顺序）

7.统一管理所依赖的jar包的版本：

对同一个框架的一组jar包，最好使用相同的版本，为了方便升级框架，可以将jar包的版本信息统一提取出来。

（1）统一声明版本号：

                         其中atguigu.spring.version部分是自定义标签。

（2）引用前面声明的版本号：

（3）其他用法：

                   注：其实properties标签配合自定义标签声明，并不是只能声明版本号。凡是需要统一声明后再引用场合均可以使用。

8.继承：（由于非compile范围的依赖信息是不能在“依赖链”中传递的，所以有需要的工程只能单独配置，这样容易造成版本的混                 乱）

           （1）如：Hello依赖的Junit：4.0

                            HelloFriend依赖的Junit：4.0

                            MakeFriend依赖的Junit：4.9

            由于Junit的依赖范围是test不能传递，所以必然会分散在各个模块工程中，这样每个工程中，Junit的版本号均需要    设定，这样就很容易造成版本不一致。

           （2）解决思路：将Junit依赖统一提取到“父工程”中，在子工程中声明Junit依赖时不指定版本，以父工程中统一设定的为准，同时也便于修改。

            （3）操作步骤：

              a.创建一个Maven工程为父工程，注意打包方式为pom。

              b.在子工程中声明对父工程的引用。

              注：此时如果子工程的 groupId 和 version 如果和父工程重复则可以删除。 

              c.将子工程的坐标中与父工程坐标中重复的内容删除。

              d.在父工程中统一Junit的依赖。将 Parent 项目中的 dependencies 标签，用 dependencyManagement 标签括起来。

              e.在子工程中删除Junit依赖的版本号部分。

注意：配置继承后，执行安装命令时，要先安装父工程，否则，子工程就无法安装了。