maven 依赖_rpm依赖判断

一、依赖

依赖是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 是默认的依赖范围。这里主要对比前三种常用的依赖范围。

type

对主程序是否有效

对测试程序是否有效

是否参与打包与部署

典型例子

compile

Y

Y

Y

log4j

test

N

Y

N

junit

provided

Y

Y

N

servlet-api

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

三、依赖的传递性

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

四、依赖的原则

最短路径优先原则：如果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来进行排除。

六、总结

在使用Maven 时，可能我们只是简单知道Maven 的用法，从而忽略了其中的一些细节。希望这篇博文能够为初步了解Maven 或只会简单使用Maven 的人提供帮助。

今天的文章maven 依赖_rpm依赖判断分享到此就结束了，感谢您的阅读。