Maven依赖管理

青山^

于 2024-08-16 19:51:59 发布

阅读量774

点赞数 15

文章标签： maven java

本文链接：https://blog.csdn.net/qq_68874993/article/details/141266160

版权

Maven 的核心功能之一是依赖管理。这一功能极大地简化了 Java 项目中库（也称为依赖）的添加、更新和冲突解决过程。Maven 通过其项目对象模型（POM, Project Object Model）和中央仓库系统来实现依赖管理。

1. 依赖声明

在 Maven 项目中，所有依赖都必须在项目的 pom.xml 文件中明确声明。通过 <dependency> 元素，可以指定所需的依赖库，包括其 GroupId、ArtifactId 和版本号。例如，如果想在的项目中添加 Junit 依赖，可以在 pom.xml 中添加类似下面的代码：

<dependencies>  
    <dependency>  
        <groupId>junit</groupId>  
        <artifactId>junit</artifactId>  
        <version>4.13.2</version>  
        <scope>test</scope>  
    </dependency>  
</dependencies>

2. 依赖传递

在 Maven 项目中，当声明一个依赖时，这个依赖本身可能还依赖于其他库。Maven 能够自动解析并下载这些传递性依赖，而无需手动声明它们。这种自动解析传递性依赖的能力极大地简化了依赖管理过程。

然而，依赖传递也可能导致问题，特别是当项目依赖于多个库，而这些库又依赖于相同但不同版本的第三方库时。这就是依赖冲突可能发生的场景。

3. 依赖范围

Maven 允许指定依赖的作用范围（scope），以控制依赖在项目的哪些部分中可用。常见的依赖范围包括：

compile：默认值，用于编译、测试和运行，也会被打包。
provided：JDK 或容器已提供，编译和测试时可用，但不会被打包。
runtime：编译时不需要，但在测试和运行时需要。
test：仅在测试编译和运行时可用，不会被打包。
system：与 provided 类似，但你需要显式提供依赖的 JAR，Maven 不会从仓库中寻找它。

4. 依赖冲突

依赖冲突发生在项目依赖的多个库之间，它们依赖于相同但版本不同的第三方库时。Maven 需要决定在最终的项目构建中使用哪个版本的库。Maven 使用一套规则来解决这些冲突，这些规则通常基于“最近者优先”（nearest dependency first）的原则。具体来说，Maven 会查看项目的依赖树，并选择路径最短的依赖（即最靠近项目的依赖）版本。

演示：

当直接引用或者间接引用出现了相同的 jar 包!这时呢，一个项目就会出现相同的重复jar 包，这就算作冲突!依赖冲突避免出现重复依赖，并且终止依赖传递！

maven自动解决依赖冲突问题能力，会按照自己的原则，进行重复依赖选择。同时也提供了手动解决冲突的方式，当需要显式地指定一个依赖的版本，以确保项目使用正确的库版本时可以使用。

如下：

依赖管理（Dependency Management）：在父 POM 中使用 <dependencyManagement> 元素来指定依赖的版本，但不实际声明它们。子模块可以继承这些依赖项，但只能声明它们而不指定版本。这样，子模块就会使用父 POM 中指定的版本。
直接依赖声明：在项目的 POM 中直接声明所需的依赖项和版本。如果项目中直接声明了一个依赖项的版本，那么 Maven 会使用该版本，而不是通过传递性依赖解析的版本。
依赖排除（Dependency Exclusions）：可以在依赖声明中使用 <exclusions> 元素来排除特定的传递性依赖。这可以防止 Maven 将这些传递性依赖包含在项目构建中。
强制版本（Dependency Enforcement）：在某些情况下，可能需要强制 Maven 使用特定版本的依赖项，即使它可能不是通过“最近者优先”规则解析的版本。这可以通过 Maven 的 dependency:tree 插件和其他相关工具来实现，但它们通常更多地用于分析和诊断依赖问题，而不是直接解决冲突。
使用属性（Properties）：在 POM 中定义属性，并在依赖版本中使用这些属性。这有助于在整个项目中保持版本一致性，并简化依赖声明的更新。