Maven 坐标与依赖配置信息详解

置顶新垣不结衣

已于 2024-09-02 19:27:29 修改

阅读量750

点赞数 23

分类专栏： maven 文章标签： maven windows linux

于 2024-08-30 10:12:01 首次发布

本文链接：https://blog.csdn.net/Mr_Susy/article/details/141710482

版权

maven 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

依赖的配置

常用命令：

命令	功能	备注
mvn dependency:list	依赖列表	Maven会自动解析所有项目的直接依赖和传递性依赖，并且根据规则正确判断每个依赖的范围，对于一些依赖冲突，也能进行调节，以确保任何一个构件只有唯一的版本在依赖中存在。在这些工作之后，最后得到的那些依赖被称为已解析依赖（Resolved Dependency）。可以运行该命令查看当前项目的已解析依赖：
mvn dependency:tree	依赖树	将直接在当前项目POM声明的依赖定义为顶层依赖，而这些顶层依赖的依赖则定义为第二层依赖，以此类推，有第三、第四层依赖。当这些依赖经Maven解析后，就会构成一个依赖树，通过这棵依赖树就能很清楚地看到某个依赖是通过哪条传递路径引入的。可以运行该命令查看当前项目的依赖树：
mvn dependency:analyze	依赖分析	使用dependency:list和dependency:tree可以帮助我们详细了解项目中所有依赖的具体信息，在此基础上，还有dependency:analyze工具可以帮助分析当前项目的依赖。

＜project＞……
    ＜dependencies＞
        ＜dependency＞
            ＜groupId＞……＜/groupId＞
            ＜artifactId＞……＜/artifactId＞
            ＜version＞……＜/version＞
            ＜type＞……＜/type＞
            ＜scope＞……＜/scope＞
            ＜optional＞……＜/optional＞
            ＜exclusions＞
                ＜exclusion＞……＜/exclusion＞……
            ＜/exclusions＞
        ＜/dependency＞……
    ＜/dependencies＞……
＜/project＞

根元素project下的dependencies可以包含一个或者多个dependency元素，以声明一个或者多个项目依赖。

每个依赖可以包含的元素有：

groupId、artifactId和version：依赖的基本坐标，对于任何一个依赖来说，基本坐标是最重要的，Maven根据坐标才能找到需要的依赖。
type：依赖的类型，对应于项目坐标定义的packaging。大部分情况下，该元素不必声明，其默认值为jar。
scope：依赖的范围
optional：标记依赖是否可选
exclusions：用来排除传递性依赖

1.依赖范围

Maven在编译项目主代码的时候需要使用一套classpath。例如，编译项目主代码的时候需要用到spring-core，该文件以依赖的方式被引入到classpath中。其次，Maven在编译和执行测试的时候会使用另外一套classpath。例如，JUnit就是一个很好的例子，该文件也以依赖的方式引入到测试使用的classpath中，不同的是这里的依赖范围是test。最后，实际运行Maven项目的时候，又会使用一套classpath，spring-core需要在该classpath中，而JUnit则不需要

依赖范围就是用来控制依赖与这三种classpath（编译classpath、测试classpath、运行classpath）的关系，Maven有以下几种依赖范围：

compile：编译依赖范围。如果没有指定，就会默认使用该依赖范围。使用此依赖范围的Maven依赖，对于编译、测试、运行三种classpath都有效。典型的例子是spring-core，在编译、测试和运行的时候都需要使用该依赖。
test：测试依赖范围。使用此依赖范围的Maven依赖，只对于测试classpath有效，在编译主代码或者运行项目的使用时将无法使用此类依赖。典型的例子是JUnit，它只有在编译测试代码及运行测试的时候才需要。
provided：已提供依赖范围。使用此依赖范围的Maven依赖，对于编译和测试class-path有效，但在运行时无效。典型的例子是servlet-api，编译和测试项目的时候需要该依赖，但在运行项目的时候，由于容器已经提供，就不需要Maven重复地引入一遍。
runtime：运行时依赖范围。使用此依赖范围的Maven依赖，对于测试和运行class-path有效，但在编译主代码时无效。典型的例子是JDBC驱动实现，项目主代码的编译只需要JDK提供的JDBC接口，只有在执行测试或者运行项目的时候才需要实现上述接口的具体JDBC驱动。
system：系统依赖范围。该依赖与三种classpath的关系，和provided依赖范围完全一致。但是，使用system范围的依赖时必须通过systemPath元素显式地指定依赖文件的路径。由于此类依赖不是通过Maven仓库解析的，而且往往与本机系统绑定，可能造成构建的不可移植，因此应该谨慎使用。

依赖范围（scope）	编译	测试	运行时	例子
compile	Y	Y	Y	spring-core
test	-	Y	-	JUnit
provided	Y	Y	-	servlet-api
runtime	-	Y	Y	JDBC驱动实现
system	Y	Y	-	本地的，Maven仓库之外的类库文件

2.传递性依赖（Transitive Dependencies）

何为传递性依赖？

account-mail有一个compile范围的spring-core依赖，spring-core有一个compile范围的commons-logging依赖，那么commons-logging就会成为account-email的compile范围依赖，commons-logging是account-email的一个传递性依赖。

了传递性依赖机制，在使用Spring Framework的时候就不用去考虑它依赖了什么，也不用担心引入多余的依赖。Maven会解析各个直接依赖的POM，将那些必要的间接依赖，以传递性依赖的形式引入到当前的项目中。

传递性依赖和依赖范围

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

	compile	test	provided	runtime
compile	compile	-	-	runtime
test	test	-	-	test
provided	provided	-	provided	provided
runtime	runtime	-	-	runtime

这里再举个例子。account-email项目有一个com.icegreen:greenmail:1.3.1b的直接依赖，我们说这是第一直接依赖，其依赖范围是test；而greenmail又有一个javax.mail:mail:1.4的直接依赖，我们说这是第二直接依赖，其依赖范围是compile。显然javax.mail:mail:1.4是account-email的传递性依赖，对照表5-2可以知道，当第一直接依赖范围为test，第二直接依赖范围是compile的时候，传递性依赖的范围是test，因此javax.mail:mail:1.4是account-email的一个范围是test的传递性依赖。

仔细观察一下表，可以发现这样的规律：当第二直接依赖的范围是compile的时候，传递性依赖的范围与第一直接依赖的范围一致；当第二直接依赖的范围是test的时候，依赖不会得以传递；当第二直接依赖的范围是provided的时候，只传递第一直接依赖范围也为provided的依赖，且传递性依赖的范围同样为provided；当第二直接依赖的范围是runtime的时候，传递性依赖的范围与第一直接依赖的范围一致，但compile例外，此时传递性依赖的范围为runtime。

3.依赖调解（Dependency mediation）

Maven引入的传递性依赖机制，一方面大大简化和方便了依赖声明，另一方面，大部分情况下我们只需要关心项目的直接依赖是什么，而不用考虑这些直接依赖会引入什么传递性依赖。但有时候，当传递性依赖造成问题的时候，我们就需要清楚地知道该传递性依赖是从哪条依赖路径引入的。

例如，项目A有这样的依赖关系：A-＞B-＞C-＞X（1.0）、A-＞D-＞X（2.0），X是A的传递性依赖，但是两条依赖路径上有两个版本的X，那么哪个X会被Maven解析使用呢？两个版本都被解析显然是不对的，因为那会造成依赖重复，因此必须选择一个。Maven依赖调解（Dependency Mediation）的第一原则是：路径最近者优先。该例中X（1.0）的路径长度为3，而X（2.0）的路径长度为2，因此X（2.0）会被解析使用。

依赖调解第一原则不能解决所有问题，比如这样的依赖关系：A-＞B-＞Y（1.0）、A-＞C-＞Y（2.0），Y（1.0）和Y（2.0）的依赖路径长度是一样的，都为2。那么到底谁会被解析使用呢？在Maven 2.0.8及之前的版本中，这是不确定的，但是从Maven 2.0.9开始，为了尽可能避免构建的不确定性，Maven定义了依赖调解的第二原则：第一声明者优先。在依赖路径长度相等的前提下，在POM中依赖声明的顺序决定了谁会被解析使用，顺序最靠前的那个依赖优胜。该例中，如果B的依赖声明在C之前，那么Y（1.0）就会被解析使用。

两条原则

引入路径短者优先：
先声明者优先

4.可选依赖（Optional Dependencies）

参考文章1:https://blog.csdn.net/weixin_43888891/article/details/130510971

参考文章2:https://blog.csdn.net/lp1302190871/article/details/13552738

optional表示是否会传递依赖，有两个可填值（假如不声明optional标签，默认就是false）：

false: 传递依赖
true：不传递依赖

举例：A引用了B的依赖，而B又引用了C依赖。

假如B引用C依赖的时候没有设置optional，那么A是可以使用C依赖的。
假如B引用C依赖的时候将optional标签设置为了true，那么在A当中就无法使用C依赖相关的方法，并且A调用B依赖的方法，而B依赖方法使用到了C，这时候会报找不到C依赖下的类，因为C不参与A的打包。

5.排除依赖（Exclusions）

  <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
            <exclusions>
                <exclusion>
                    <groupId>org.junit.vintage</groupId>
                    <artifactId>junit-vintage-engine</artifactId>
                </exclusion>
            </exclusions>
        </dependency>