Maven 核心依赖和构建管理

一、依赖管理和配置

Maven 依赖管理是 Maven 软件中最重要的功能之一。Maven 的依赖管理能够帮助开发人员自动解决软件包依赖问题，使得开发人员能够轻松地将其他开发人员开发的模块或第三方框架集成到自己的应用程序或模块中，避免出现版本冲突和依赖缺失等问题。

我们通过定义 POM 文件，Maven 能够自动解析项目的依赖关系，并通过 Maven 仓库自动下载和管理依赖，从而避免了手动下载和管理依赖的繁琐工作和可能引发的版本冲突问题。

maven项目信息属性配置和读取：

<!-- 模型版本 -->
<modelVersion>4.0.0</modelVersion>
<!-- 公司或者组织的唯一标志，并且配置时生成的路径也是由此生成， 如com.companyname.project-group，maven会将该项目打成的jar包放本地路径：/com/companyname/project-group -->
<groupId>com.companyname.project-group</groupId>
<!-- 项目的唯一ID，一个groupId下面可能多个项目，就是靠artifactId来区分的 -->
<artifactId>project</artifactId>
<!-- 版本号 -->
<version>1.0.0</version>

<!--打包方式
    默认：jar
    jar指的是普通的java项目打包方式！ 项目打成jar包！
    war指的是web项目打包方式！项目打成war包！
    pom不会讲项目打包！这个项目作为父工程，被其他工程聚合或者继承！后面会讲解两个概念
-->
<packaging>jar/pom/war</packaging>

 依赖管理和添加：

<!-- 
   通过编写依赖jar包的gav必要属性，引入第三方依赖！
   scope属性是可选的，可以指定依赖生效范围！
   依赖信息查询方式：
      1. maven仓库信息官网 https://mvnrepository.com/
      2. mavensearch插件搜索
 -->
<dependencies>
    <!-- 引入具体的依赖包 -->
    <dependency>
        <groupId>log4j</groupId>
        <artifactId>log4j</artifactId>
        <version>1.2.17</version>
        <!--
            生效范围
            - compile ：main目录 test目录  打包运行 [默认]
            - provided：main目录 test目录  Servlet
            - runtime： 打包运行           MySQL
            - test:     test目录           junit
         -->
        <scope>runtime</scope>
    </dependency>

</dependencies>

 依赖版本提取和维护:

<!--声明版本-->
<properties>
  <!--命名随便,内部制定版本号即可！-->
  <junit.version>4.11</junit.version>
  <!-- 也可以通过 maven规定的固定的key，配置maven的参数！如下配置编码格式！-->
  <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
</properties>

<dependencies>
  <dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <!--引用properties声明版本 -->
    <version>${junit.version}</version>
  </dependency>
</dependencies>

二、依赖传递和冲突

依赖传递指的是当一个模块或库 A 依赖于另一个模块或库 B，而 B 又依赖于模块或库 C，那么 A 会间接依赖于 C。这种依赖传递结构可以形成一个依赖树。当我们引入一个库或框架时，构建工具（如 Maven、Gradle）会自动解析和加载其所有的直接和间接依赖，确保这些依赖都可用。

依赖传递的作用：

（1）减少重复依赖：当多个项目依赖同一个库时，Maven 可以自动下载并且只下载一次该库。这样可以减少项目的构建时间和磁盘空间。

（2）自动管理依赖: Maven 可以自动管理依赖项，使用依赖传递，简化了依赖项的管理，使项目构建更加可靠和一致。

（3）确保依赖版本正确性：通过依赖传递的依赖，之间都不会存在版本兼容性问题，确实依赖的版本正确性。

依赖传递演示：

项目中，需要导入 jackson 相关的依赖，通过之前导入经验，jackson 需要导入三个依赖，分别为：

通过查看网站介绍的依赖传递特性：data-bind 中，依赖其他两个依赖

 最佳导入：直接可以导入 data-bind，自动传递依赖需要的依赖

<!-- https://mvnrepository.com/artifact/com.fasterxml.jackson.core/jackson-databind -->
<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-databind</artifactId>
    <version>2.15.0</version>
</dependency>

依赖冲突演示：

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

maven 自动解决依赖冲突问题能力，会按照自己的原则，进行重复依赖选择。同时也提供了手动解决的冲突的方式，不过不推荐。

解决依赖冲突（如何选择重复依赖）方式：

（1）短路优先原则（第一原则）

A—>B—>C—>D—>E—>X(version 0.0.1)

A—>F—>X(version 0.0.2)

则A依赖于X(version 0.0.2)

（2）依赖路径长度相同情况下，则“先声明优先”（第二原则）

A—>E—>X(version 0.0.1)

A—>F—>X(version 0.0.2)

在<depencies></depencies>中，先声明的，路径相同，会优先选择。

三、依赖导入失败情况及解决方案

在使用 Maven 构建项目时，可能会发生依赖项下载错误的情况，主要原因有以下几种：

（1）下载依赖时出现网络故障或仓库服务器宕机等原因，导致无法连接至 Maven 仓库，从而无法下载依赖。

（2）依赖项的版本号或配置文件中的版本号错误，或者依赖项没有正确定义，导致 Maven 下载的依赖项与实际需要的不一致，从而引发错误。

（3）本地 Maven 仓库或缓存被污染或损坏，导致 Maven 无法正确地使用现有的依赖项，并且也无法重新下载。

解决方案：

（1）检查网络连接和 Maven 仓库服务器状态。

（2）确保依赖项的版本号与项目对应的版本号匹配，并检查 POM 文件中的依赖项是否正确。

（3）清除本地 Maven 仓库缓存（lastUpdated 文件），因为只要存在 lastupdated 缓存文件，刷新也不会重新下载。本地仓库中，根据依赖的 gav 属性依次向下查找文件夹，最终删除内部的文件，刷新重新下载即可。

例如： pom.xml 依赖

<dependency>
  <groupId>com.alibaba</groupId>
  <artifactId>druid</artifactId>
  <version>1.2.8</version>
</dependency>

文件：

 脚本使用：

@echo off
rem 这里写你的仓库路径
set REPOSITORY_PATH=D:\repository
rem 正在搜索...
for /f "delims=" %%i in ('dir /b /s "%REPOSITORY_PATH%\*lastUpdated*"') do (
    del /s /q %%i
)
rem 搜索完毕
pause

注：将脚本内容复制到文本文件中，set REPOSITORY_PATH=D:\repository 改成你本地仓库地址，然后将文件的后缀名改为 .bat，最后点击运行脚本，即可自动清理本地错误缓存文件。

四、扩展构建管理和插件配置

构建概念:项目构建是指将源代码、依赖库和资源文件等转换成可执行或可部署的应用程序的过程，在这个过程中包括编译源代码、链接依赖库、打包和部署等多个步骤。

主动触发场景：

（1）重新编译 : 编译不充分，部分文件没有被编译。

（2）打包 : 独立部署到外部服务器软件，打包部署。

（3）部署本地或者私服仓库 : maven 工程加入到本地或者私服仓库，供其他工程使用。

命令方式构建:

语法: mvn 构建命令 构建命令.... 

命令	描述
mvn clean	清理编译或打包后的项目结构,删除target文件夹
mvn compile	编译项目，生成target文件
mvn test	执行测试源码 (测试)
mvn site	生成一个项目依赖信息的展示页面
mvn package	打包项目，生成war / jar 文件
mvn install	打包后上传到maven本地仓库(本地部署)
mvn deploy	只打包，上传到maven私服仓库(私服部署)

可视化方式构建:

构建命令周期:

构建命令周期可以理解成是一组固定构建命令的有序集合，触发周期后的命令，会自动触发周期前的命令。也是一种简化构建的思路。

（1）清理周期：主要是对项目编译生成文件进行清理

包含命令：clean

（2）默认周期：定义了真正构件时所需要执行的所有步骤，它是生命周期中最核心的部分

包含命令：compile - test - package - install / deploy

（3）报告周期

包含命令：site

打包: mvn clean package 本地仓库: mvn clean install

最佳使用方案:

打包: mvn clean package
重新编译: mvn clean compile
本地部署: mvn clean install 

周期，命令和插件:

周期→包含若干命令→包含若干插件

使用周期命令构建，简化构建过程。最终进行构建的是插件。

注：jdk17 和 war 包版本插件不匹配会导致打包失败，此时需要手动引入插件

<build>
   <!-- jdk17 和 war包版本插件不匹配 -->
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-war-plugin</artifactId>
            <version>3.2.2</version>
        </plugin>
    </plugins>
</build>