CFSDN坚持开源创造价值，我们致力于搭建一个资源共享平台，让每一个IT人在这里找到属于你的精彩世界.

这篇CFSDN的博客文章深入理解Maven的坐标与依赖由作者收集整理，如果你对这篇文章有兴趣，记得点赞哟.

在前边两节中，我们学习了maven的基本概念以及何为maven仓库，并且如何配置settings.xml文件等相关知识点。maven的主要作用是可以帮助我们自动下载在pom.xml中配置添加的依赖。那么在本节中，我们将学习如何引入依赖.

知识点包括:

maven的坐标，maven的依赖配置，依赖范围，传递性依赖，依赖调解，可选依赖，排除依赖，归类依赖和优化依赖 。

maven的坐标 。

maven的仓库中拥有着无数的构件，每一个构件都是一个jar或者war等文件，如果没有坐标，那么我们将无法唯一标识该构件，结果就是maven将无法帮助我们自动下载构件。所以，maven定义了一组规则：世界上任何一个构件都可以使用maven坐标来唯一标识。maven坐标的主要元素包括groupid，artifactid，version，packaging（可选）和classifier（可选），通过这些元素，我们可以明确标识任何一个构件.

groupid：该元素定义了当前maven项目隶属的实际项目，一般情况下该项元素都与公司域名相对应，比如com.taobao. 。

artifactid：该元素定义了实际项目中的一个maven module 。

version：该元素表示当前构件的版本，包括稳定（release）版本和测试（snapshot）版本 。

packaging：该元素定义maven项目的打包方式，默认为jar，还有war和pom方式 。

classifer：该元素用来帮助定义构件输出的一些附属构件，例如通过配置插件，可以在打包的同时生成-javadoc.jar和sources.jar等构件.

示例如下:

maven的依赖 。

依赖配置 。

上边生成的jar包为passport-agent-0.0.1-snapshot-jdk15-javadoc.jar，若其它项目中需要依赖该jar包，那么需要引入的配置如下:

上边的配置<dependency>标签其实就是在将我们项目中所需要的依赖配置在pom.xml，标签已经定义好了该构件的坐标，那么maven会根据该配置从仓库中下载构件。既然学会了如何在项目中配置引入依赖，那么我们接下来说说依赖相关的事儿吧.

依赖范围 。

maven有如下6种依赖范围:

1. compile: 编译依赖范围(default，大多数情况下我们都是在使用compile编译范围)
2. test: 测试依赖范围 （编译主代码和运行时无效）
3. provided: 已提供依赖范围（就是说在运行的时候容器已经给我们提供该依赖了，比如说servlet-api）
4. runtime: 运行时依赖范围
5. system: 系统依赖范围(生成的构建一般与本机系统绑定，不具备移植性不建议使用)
6. import: 导入依赖范围（将其它地方官依赖配置导入，后续讲到依赖管理dependencymanagement详细阐述）

我们以表格来说明下各个依赖的生效范围:

  。

  。

传递性依赖 。

传递性依赖的意思是依赖具有传递性。比如，在a 中添加对b 的依赖，在b 中添加对c 的依赖，如果依赖范围是compile 的，a 不仅会有b 的jar 包，也会有c 的jar 包。如果在c 中添加了某个依赖，那么根据传递性，a 和b 也可以使用c添加的依赖，而不需要自己再重新引入依赖。 我们使用公式来表示依赖的传递性:

 a->b并且b->c，那么a->c，也就是c是一个a的传递性依赖 。

依赖调解 。

依赖调解是指当存在多个传递性依赖时，出现了当前项目对于同一个依赖有多个版本被引入依赖树中该如何选择的原则.

比如说存在以下情况:

存在：a->-b>-c->x(1.0)和a->d->x(2.0) 。

原则：路径最近原则（指依赖通过几层传递性依赖引入），x(2.0)将会被解析 。

存在：a->b->y(1.0)和a->c->y(2.0) 。

原则：第一声明优先原则，哪个现在pom中声明（也就是在pom文件的上边），就以哪个为准（maven2.0.9开始使用，在此之前是不确定的，导致构建项目具有一定的随机性） 。

可选依赖 。

a->b，并且b->x(可选)，b->y(可选)，那么x，y将不会对a有任何影响.

可选依赖使用<optional>true</optional>设置。可选依赖违反了单一职责的原则，一般不建议使用.

排除依赖 。

我们通过在pom中配置<dependency></dependency>来引入依赖，但是该依赖存在多个传递性依赖，如果某个间接依赖不是我们需要的，影响到了我们项目的正常构建，那么我们可以使用<exclusions><exclusion></exclusion></exclusions>来干掉它。示例如下:

在上边的配置中，我们引入了xx-serviceapi的依赖，但是我们将该依赖所引入的org.apache.thrift和ipwrapper依赖都给排除掉了，这两个依赖将不会出现在我们构建的项目中.

归类依赖 。

归类依赖看着高大上，其实说白了就是为了统一管理依赖，如果某些依赖的version都是一致的或者是存在某些特殊的关系，我们可以在pom中使用<properties></properties>配置一些变量，在下边的时候使用$变量名来搞定.

优化依赖 。

优化依赖的意思是通过优化，使得我们的项目对于引入的依赖优化一点^_^，比如说去除多余的依赖等操作。那么我们如何实现呢？这个时候我们的插件（后边详细介绍）maven-dependency-plugin该上场了。不知各位是否还记得我们前面所说的超级pom文件，在该文件中，定义了该插件（见下图），所以我们在maven项目中可以直接使用该dependency插件.

我们主要使用该插件的三个任务(goal)：list，tree, anaylze（何为插件，何为插件goal我们后边详细街上，此处只要知道插件可以用来帮你干活就ok了哈） 。

我们先来看一下这条命令mvn dependency:list的执行结果吧.

这条命令的执行结果告诉你当前项目passport-common中引入的依赖有哪些，并且直接列出。但是其实这样的结果对于我们程序员来说意义并不是很大，只是一些简单的依赖罗列，看不出某个具体的依赖是直接还是被间接引入本项目的。这个时候我们需要使用mvn dependency:tree 将依赖以树的形式展示出来。结果如下:

在这个依赖树中，开头从最左边开始的，说明这个依赖是被直接引入的依赖a，我们还可以看到该直接依赖a又给本项目引入了哪些间接依赖。依赖树的好处就在于，当我们想使用<exclusions><exclusion></exclusion></exclusions>标签将某些依赖排除掉时，可以准确的确定出该间接依赖所对应的直接依赖.

那么，当我们想进一步优化该项目的依赖呢？比如我们想看看哪些依赖是没有被使用的？或者哪些依赖没有显示声明配置，然而却被直接调用呢？也就是优化依赖，使得项目更加简洁稳定。这个时候我们需要使用mvn dependency:analyze 了，该命令可以分析项目中依赖的具体使用情况。结果如下:

分析结果中，将依赖分为了两种，即used undeclared dependencies found 和unused declared dependencies found两种 。

（1）used undeclared dependencies found ：使用了但是没有显示的声明该依赖 。

这种情况对于我们的项目构建是不利的，存在着潜在的风险，这些依赖是通过间接依赖引入项目的，当我们需要升级直接依赖的版本时，可能会导致间接依赖的版本出现变动，从而影响到项目的构建，所以我们需要显示声明任何项目中直接使用到的依赖.

（2）unused declared dependencies found：声明了该依赖但是并没有被使用 。

出现这种情况也我们不能简单的将该依赖的声明和配置删掉了事，应该具体分析。因为mvn dependency:analyze只会分析编译主代码和测试代码需要用到的依赖，一些执行测试和与运行时需要的依赖它就分析不出来。所以需要具体分析项目依赖情况.

总结 。

这篇文章我们学习了maven的坐标和依赖的相关知，结合前边章节的学习，我们知道了仓库是用来存储构件（依赖）的，项目中需要的各种依赖通过maven坐标存在各个仓库（本地仓库和远程仓库等）中。配置文件settings.xml和项目中的pom.xml都是对仓库，依赖和插件进行各种配置的，最终目的就是通过配置依赖，使得maven可以帮助我们自动下载依赖，减去了我们需要去网站上的各个地方去手动搜索和下载依赖的烦恼.

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持我.

原文链接：https://blog.csdn.net/qq_25827845/article/details/83628045 。

最后此篇关于深入理解Maven的坐标与依赖的文章就讲到这里了,如果你想了解更多关于深入理解Maven的坐标与依赖的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。