Maven的依赖

近段时间在研究sonar扫描java项目，成功扫描sonar官方的示例java项目后，扫描公司的java项目出错，几经摸索，后来更换了公司项目中的pom.xml文件内容，才扫描成功，但还是有些报错，我认为还没研究透彻，个人觉得有必要学习maven的pom.xml文件的具体配置，弄清楚其中标签的具体意思，一是希望可以解决现在的报错，二是希望下次再此类遇到问题时，我可以自己快速修改配置文件解决问题。

一、依赖

依赖是 Maven 中最关键的部分，我们之所以在工程中使用Maven，就是因为它的依赖管理功能。如果我们想要在工程中引入某个jar 包，只需要在pom.xml 中引入其jar 包的坐标即可。比如引入log4j 的依赖：

    <dependencies>
        <dependency>
            <groupId>log4j</groupId>
            <artifactId>log4j</artifactId>
            <version>1.2.17</version>
            <scope>compile</scope>
        </dependency>
    </dependencies>

Maven 通过groupId、artifactId与version三个向量来定位Maven 仓库其jar 包所在的位置，并把对应的jar 包引入到工程中来。

二、依赖范围

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

依赖的范围，是指引入依赖的作用范围。

Maven 提供了六种依赖的范围：compile、test、provided、runtime、system 和import。其中compile 是默认的依赖范围。

• compile：是默认的依赖范围，代表引入依赖作用于主程序、测试程序、部署运行

• test：只对测试程序有效，如junit在单元测试的时候才使用，主程序和部署运行都不使用

• provided：不需要参与最终的部署，例如servlet-api.jar，因为项目部署到tomcat中时，tomcat中包含该依赖会导致冲突

• runtime：不参与主程序的编译
  例如：mysql-connection.jar

• system：系统依赖范围。从参与度来说，和provided相同，不过被依赖项不会从maven仓库下载，而是从本地文件系统拿。需要添加systemPath的属性来定义路径，可能造成不可移植，谨慎使用。

三、依赖的传递性

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

依赖范围是compile，才能进行传递。

四、依赖的原则

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

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

五、依赖的排除

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

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

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

六、统一管理依赖的版本

可以自定义标签，将各种依赖版本抽出来，后面进行引用。全部版本放在一起，一目了然。在需要修改版本的时候，只需要在自定义标签那里修改即可。

————————————————
参考：https://blog.csdn.net/codejas/article/details/79490030