手表网站制作推广产品的方法和步骤

一、依赖范围

在引入log4j 依赖的时候，有一个scope设置，这个scope设置的值就是对应的依赖范围(因为compile 是默认的依赖范围，所以有时也可以省略)。

Maven 提供了六种依赖的范围：compile、test、provided、runtime、system 和import。其中compile 是默认的依赖范围。这里主要对比前三种常用的依赖范围。

需要注意的是：
provided 范围依赖是不参与项目打包与部署的，比如 servlet-api，如果你把
scope改成compile 范围的依赖，就会因为jar 包冲突报错。原因是我们在启动web 项目时，tomcat 已经在启动时加载了自身的 servlet-api。

二、依赖的传递性

依赖的传递性是指：在A 中添加对B 的依赖，在B 中添加对C 的依赖，如果依赖范围是
compile 的，A 不仅会有B 的jar 包，也会有C 的jar 包。如果在C 中添加了某个依赖，那么根据传递性，A 和B 也可以使用 C 添加的依赖，而不需要自己再重新引入依赖。

三、依赖的原则

• 最短路径优先原则：如果A 依赖于B，B 依赖于C，在B 和C 中同时有log4j 的依赖，并且这两个版本不一致，那么A 会根据最短路径原则，在A 中会传递过来B 的log4j版本。
  

• 路径相同先声明原则：如果在A 同时依赖于B 和C，B 和C 没有依赖关系，并且都有log4j 的依赖，且版本不一致，那么A 会引入在pom.xml 中先声明依赖的log4j 版本。
  

四、依赖的排除

我们在当前工程中引入了A 的依赖，而A 同时有对B 的依赖，根据传递性我们知道，在当前工程中会自动引入对B 的依赖。其中B 可能是一个不稳定的版本，或者对当前的工程存在着不良的影响 。这时我们就可以在引入对A 依赖的同时排除对B 的依赖。

下面我们以spriing-core 为例，当我们在pom.xml中引入对spriing-core 的同时，会自动将commons-logging 的jar 包引入进来。如下所示：

假设这个commons-logging 是一个不稳定的版本(只是假设)，我们希望在引入spriing-core 时排除commons-logging。这时我们可以使用exclusion来进行排除。