Maven专题1——坐标与依赖

Posted 2022-06-16 zyon

坐标

坐标用来唯一定位一个Maven构件：

• GAV(必需)：groupId, artifactId, version
• packaging(可选): 可取值如：jar(缺省), war, pom, maven-plugin等，其中父项目的packaging通常是pom，只用来声明项目元数据，用到的依赖、插件，以及项目中的子模块等。
• classifier: 不能直接定义，通常用来辅助定义附属构件，如：javadoc、sources构件等。

依赖

在POM的<dependency>元素中，有以下元素可以用来配置依赖：

• GAV：groupId、artifactId、version。

• type：对应于被依赖模块的packaging元素的值。

• scope:

compile：默认依赖范围，对编译、测试、运行三种classpath都有效，用于编译、测试、运行阶段都需要用到的依赖；
test：只对测试classpath有效，编译主代码、运行项目时无法使用的依赖。
provided：对编译、测试有效，在运行时无效。
runtime：运行时依赖，对测试、运行classpath有效，在编译主代码时无效；
import：不会对编译、测试、运行的classpath产生实际影响，
system：需通过systemPath显式指定依赖的路径，不通过Maven仓库解析，会造成构建的不可移植，不推荐使用。

• optional：标记依赖是否可选；

• exclusions：排除某些传递依赖。

管理type为pom类型的依赖

通常一个项目的pom类型的构件用来声明使用到的依赖，为了沿用和管理其声明的所有依赖，通常可以在dependencyManagement元素中如下引用：

<dependencyManagement>
    <dependencies>
        <dependency>
            <artifactId>org.springframework.boot</artifactId>
            <groupId>spring-boot-dependencies</groupId>
            <version>$spring.boot.version</version>
            <scope>import</scope>
            <type>pom</type>
        </dependency>
    </dependencies>
</dependencyManagement>

以此来保持我们项目使用的依赖和Spring Boot声明的一致。

依赖范围与classpath关系

依赖范围	对编译classpath有效	对测试classpath有效	对运行时classpath有效	示例
compile	Y	Y	Y	spring-core
provided	Y	Y	-	servlet-api
runtime	-	Y	Y	JDBC驱动
test	-	Y	-	JUnit
system	Y	Y	-	本地Maven仓库以外的类库文件

依赖范围与依赖传递的关系

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

表格说明：

1. 最左侧列是第一直接依赖，如A依赖于B，B依赖于C时，A对于B即是第1直接依赖；
2. 最上侧行是第2直接依赖，如A依赖于B，B依赖于C时，B对于C即是第2直接依赖；
3. 表中其他单元格表示传递依赖的依赖范围，即A传递依赖C的范围。

结论：

1. 第2直接依赖的范围是compile时，传递依赖的范围与第1直接依赖一致；
2. 第2直接依赖是test时，依赖不会传递；
3. 第2直接依赖是provided时，只传递依赖第1直接依赖也是provided范围的依赖。

依赖调解

1. 路径最近者优先，例如：A->B->c->x(1.0)，a->d->x(2.0)，由于a通过第二条路径依赖x的距离更短，因此实际解析使用的是2.0的x。
2. 最先声明者优先，例如：a->b->y(1.0)，a->c->y(2.0)，在依赖路径等长时，声明依赖b在声明c之前，则实际解析使用的是y(1.0)。

可选依赖

optional元素是true的依赖是可选依赖。

可选依赖通常用来阻断依赖传递，例如a->b，b->x(可选)、b->y(可选)。

这种情况通常出现在b有多种实现，一种可以使用x，另一种可以使用y的场景。

此时考虑非可选的场景，如果上述3个依赖范围都是compile，那么x和y也应该是a的compile依赖。

然而在可选依赖的场景下，依赖传递被打破，x和y只会对声明可选依赖于他们的b有影响，a并不会传递依赖x和y。

当声明a依赖于b时，就要指明a选择使用b依赖的x还是y，即需要在a中显式的声明依赖x或y。

对于存在可选依赖的场景，应考虑针对每一种可选依赖建立一个独立的模块对外提供功能，从而不使用可选依赖这个概念。

优化依赖

使用列表的形式查看依赖：

mvn dependency:list

使用树形结构查看依赖树：

mvn dependency:tree

分析依赖状况：

mvn dependency:analyze

analyze会列出两类重点关注的依赖：

1. 使用但未声明的依赖：指项目中使用到，但是是通过传递依赖传递进来的。
2. 声明但未使用的依赖：项目中声明了但未使用的依赖，该命令只列出编译主代码、测试代码需要的依赖，并不会发现执行测试和运行时需要的依赖，所以不应该简单地删除声明了但未使用的依赖。