关于Maven的重要知识点，都在这篇文章了

顶尖程序员：）

已于 2023-11-28 09:10:30 修改

阅读量336

点赞数 12

分类专栏： maven 文章标签： java maven

于 2023-11-27 22:18:25 首次发布

本文链接：https://blog.csdn.net/yuanmintao/article/details/134655485

版权

maven 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

1. Maven依赖调解（Dependency Mediation）的第一原则是：路径最近者优先。

2. 依赖调解的第二原则：第一声明者优先。

一、maven坐标

1. groupId

groupid是定义当前Maven项目隶属的实际项目。

比如SpringFramework这一实际项目，其对应的Maven项目会有很多，如spring-core、spring-context等。一个实际项目往往会被划分成很多Maven项目（模块）。

groupId的表示方式与Java包名的表示方式类似，通常与域名反向一一对应。例如groupId为org.sonatype.nexus, org.sonatype表示Sonatype公司建立的一个非盈利性组织，nexus表示Nexus这一实际项目，该groupId与域名nexus.sonatype.org对应。

2. artifactId

artifactId是定义实际项目中的一个Maven项目（模块），推荐的做法是使用实际项目名称作为artifactId的前缀。

例如artifactId是nexus-indexer，使用了实际项目名nexus作为前缀，这样做的好处是方便寻找实际构件。

二、依赖范围

1. compile

编译依赖范围。默认设置。对于编译、测试、运行三种classpath都有效。

2. test

测试依赖范围。只对于测试classpath有效，在编译主代码或者运行项目的使用时将无法使用此类依赖。例如JUnit。

3. provided

已提供依赖范围。对于编译和测试classpath有效，但在运行时无效。例如servlet-api，在运行时，由于容器已经提供，不需要重复引入。

4. runtime

运行时依赖范围。对于测试和运行classpath有效，但在编译时无效。例如JDBC驱动实现，编译时只需要JDK提供的JDBC接口，只有在执行测试或者运行项目的时候才需要实现上述接口的具体JDBC驱动。

5. system

系统依赖范围。该依赖与三种classpath的关系，和provided依赖范围完全一致。但是，使用system范围的依赖时必须通过systemPath元素显式地指定依赖文件的路径。由于此类依赖不是通过Maven仓库解析的，而且往往与本机系统绑定，可能造成构建的不可移植，因此应该谨慎使用。

6. import

导入依赖范围。

三、传递性依赖

假设A依赖于B,B依赖于C，我们说A对于B是第一直接依赖，B对于C是第二直接依赖，A对于C是传递性依赖。第一直接依赖的范围和第二直接依赖的范围决定了传递性依赖的范围，如表所示，最左边一列表示第一直接依赖范围，最上面一行表示第二直接依赖范围，中间的交叉单元格则表示传递性依赖范围。

四、依赖调解

1. Maven依赖调解（Dependency Mediation）的第一原则是：路径最近者优先。

例如，项目A有这样的依赖关系：A-＞B-＞C-＞X（1.0）、A-＞D-＞X（2.0），其中X（1.0）的路径长度为3，而X（2.0）的路径长度为2，因此X（2.0）会被解析使用。

2. 依赖调解的第二原则：第一声明者优先。

在依赖路径长度相等的前提下，在POM中依赖声明的顺序决定了谁会被解析使用，顺序最靠前的那个依赖优胜。

比如这样的依赖关系：A-＞B-＞Y（1.0）、A-＞C-＞Y（2.0），Y（1.0）和Y（2.0）的依赖路径长度是一样的，都为2。如果B的依赖声明在C之前，那么Y（1.0）就会被解析使用。

五、依赖优化

Maven会自动解析所有项目的直接依赖和传递性依赖，并且根据规则正确判断每个依赖的范围，对于一些依赖冲突，也能进行调节，以确保任何一个构件只有唯一的版本在依赖中存在。

查看当前项目的已解析依赖：mvn dependency:list

查看当前项目的依赖树：mvn dependency:tree

帮助分析当前项目的依赖: mvn dependency:analyze。结果中重要的有两个部分。

首先是Used undeclared dependencies，意指项目中使用到的，但是没有显式声明的依赖。这种依赖意味着潜在的风险，当前项目直接在使用它们，例如有很多相关的Java import声明，而这种依赖是通过直接依赖传递进来的，当升级直接依赖的时候，相关传递性依赖的版本也可能发生变化，这种变化不易察觉，但是有可能导致当前项目出错。显式声明任何项目中直接用到的依赖。

还有一个重要的部分是Unused declared dependencies，意指项目中未使用的，但显式声明的依赖。需要注意的是，对于这样一类依赖，我们不应该简单地直接删除其声明，而是应该仔细分析。由于dependency:analyze只会分析编译主代码和测试代码需要用到的依赖，一些执行测试和运行时需要的依赖它就发现不了。

六、依赖管理

Maven提供的dependencyManagement元素既能让子模块继承到父模块的依赖配置，又能保证子模块依赖使用的灵活性。在dependencyManagement元素下的依赖声明不会引入实际的依赖，不过它能够约束dependencies下的依赖使用。

完整的依赖声明已经包含在父POM中，子模块只需要配置简单的groupId和artifactId就能获得对应的依赖信息，从而引入正确的依赖。

使用这种依赖管理机制似乎不能减少太多的POM配置，不过还是强烈推荐采用这种方法。其主要原因在于在父POM中使用dependencyManagement声明依赖能够统一项目范围中依赖的版本，当依赖版本在父POM中声明之后，子模块在使用依赖的时候就无须声明版本，也就不会发生多个子模块使用依赖版本不一致的情况。这可以帮助降低依赖冲突的几率。

想要在另外一个模块中使用与代码清单8-14完全一样的dependencyManagement配置，除了复制配置或者继承这两种方式之外，还可以使用import范围依赖将这一配置导入：

＜dependencyManagement＞
    ＜dependencies＞
        ＜dependency＞
            ＜groupId＞com.juvenxu.mvnbook.account＜/groupId＞
            ＜artifactId＞account-parent＜/artifactId＞
            ＜version＞1.0-SNAPSHOT＜/version＞
            ＜type＞pom＜/type＞
            ＜scope＞import＜/scope＞
        ＜/dependency＞
    ＜/dependencies＞
＜/dependencyManagement＞