Maven基础

雨空集

已于 2024-03-10 16:10:05 修改

阅读量901

点赞数 19

分类专栏： # Maven / Gradle 文章标签： maven java 笔记学习

于 2024-03-10 16:04:18 首次发布

本文链接：https://blog.csdn.net/Sakurapaid/article/details/136603665

版权

Maven / Gradle 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

注：此笔记有参考于尚硅谷的Maven视频教程，也有自己的理解和看法

3.2. IDEA构建Mave Java SE工程

3.3. IDEA构建Maven Java Web工程

3.3.1. 手动创建

3.3.2. 插件创建

3.4. 将Maven的Web工程部署到tomcat

4.5. 构建插件、命令、生命周期命令之间关系

5. 基于IDEA 进行Maven依赖管理

5.1. 依赖管理概念

5.2. Maven工程核心信息配置和解读（GAVP）

5.3. Maven工程依赖管理配置

5.4. 依赖范围

5.5. Maven工程依赖下载失败错误解决（重点）

5.6. Maven工程Build构建配置

1. Maven简介

1.1. 为什么学习Maven

学习Maven的原因主要包括以下几个方面：

1.1.1. 依赖管理

随着现代软件开发中框架和库的广泛使用，项目的jar包数量急剧增长，手动管理这些jar包及其版本变得极其困难和低效。Maven作为一个强大的依赖管理工具，它允许开发者通过声明式配置轻松管理项目依赖，简化jar包的添加、升级和解决依赖冲突的过程。只需在pom.xml文件中配置所需的依赖坐标，Maven就能自动从中央仓库下载并管理这些依赖及其传递性依赖，极大地提高了效率和准确性。

①jar 包的规模

随着我们使用越来越多的框架，或者框架封装程度越来越高，项目中使用的jar包也越来越多。项目中，一个模块里面用到上百个jar包是非常正常的。

比如下面的例子，我们只用到 SpringBoot、SpringCloud 框架中的三个功能：

Nacos 服务注册发现
Web 框架环境
视图模板技术 Thymeleaf

最终却导入了 106 个 jar 包：

org.springframework.security:spring-security-rsa:jar:1.0.9.RELEASE:compile
......（此处省略）
org.springframework.cloud:spring-cloud-netflix-archaius:jar:2.2.6.RELEASE:compile

而如果使用 Maven 来引入这些 jar 包只需要配置三个『依赖』：

<!-- Nacos 服务注册发现启动器 -->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

<!-- web启动器依赖 -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

<!-- 视图模板技术 thymeleaf -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-thymeleaf</artifactId>
</dependency>

②jar包的来源问题

这个jar包所属技术的官网。官网通常是英文界面，网站的结构又不尽相同，甚至找到下载链接还发现需要通过特殊的工具下载。
第三方网站提供下载。问题是不规范，在使用过程中会出现各种问题。

- jar包的名称
- jar包的版本
- jar包内的具体细节

而使用 Maven 后，依赖对应的 jar 包能够自动下载，方便、快捷又规范。

③jar包的导入问题

在web工程中，jar包必须存放在指定位置：

在使用Maven之后，通过配置依赖(jar包)的坐标，查找本地仓库中相应jar包，若本地仓库没有，则统一从镜像网站或中央仓库中下载：

④jar包之间的依赖

框架中使用的 jar 包，不仅数量庞大，而且彼此之间存在错综复杂的依赖关系。依赖关系的复杂程度，已经上升到了完全不能靠人力手动解决的程度。另外，jar 包之间有可能产生冲突。进一步增加了我们在 jar 包使用过程中的难度。

下面是前面例子中 jar 包之间的依赖关系：

而实际上 jar 包之间的依赖关系是普遍存在的，如果要由程序员手动梳理无疑会增加极高的学习成本，而这些工作又对实现业务功能毫无帮助。

而使用 Maven 则几乎不需要管理这些关系，极个别的地方调整一下即可，极大的减轻了我们的工作量。

1.1.2. 构建自动化

Maven不仅是依赖管理工具，更是一个构建工具，它可以自动化项目的构建过程，包括编译、测试、打包、部署等一系列任务。在IDEA等集成开发环境中，虽然IDE可以处理大部分构建工作，但在脱离IDE的情况下，例如持续集成/持续部署(CI/CD)场景下，Maven能确保构建过程的一致性和可移植性。

①你没有注意过的构建

你可以不使用 Maven，但是构建必须要做。当我们使用 IDEA 进行开发时，构建是 IDEA 替我们做的。

②脱离 IDE 环境仍需构建

1.1.3. 标准化与规范化

Maven采用了一套标准化的构建生命周期和约定优于配置的策略，使得团队成员能够快速上手项目构建，降低沟通成本，提升协作效率。

综上所述，学习Maven是为了高效、准确地管理项目依赖，并实现构建过程的自动化，从而更好地适应现代软件开发的需求，提高开发效率，保障项目的稳定性和可维护性。

1.2. 什么是Maven

Maven 是一款为 Java 项目管理构建、依赖管理的工具（软件），使用 Maven 可以自动化构建、测试、打包和发布项目，大大提高了开发效率和质量。

Maven就是一个软件，掌握安装、配置、以及基本功能 （项目构建、依赖管理） 的理解和使用即可！

依赖管理：Maven 可以管理项目的依赖，包括自动下载所需依赖库、自动下载依赖需要的依赖并且保证版本没有冲突、依赖版本管理等。通过 Maven，我们可以方便地维护项目所依赖的外部库，避免版本冲突和转换错误等，而我们仅仅需要编写配置即可。
构建管理：项目构建是指将源代码、配置文件、资源文件等转化为能够运行或部署的应用程序或库的过程Maven 可以管理项目的编译、测试、打包、部署等构建过程。通过实现标准的构建生命周期，Maven 可以确保每一个构建过程都遵循同样的规则和最佳实践。同时，Maven 的插件机制也使得开发者可以对构建过程进行扩展和定制。主动触发构建，只需要简单的命令操作即可。

场景1： 例如我们项目需要第三方依赖如：Druid连接池、MySQL数据库驱动和Jackson JSON等处理。那么我们可以将想要的依赖项的信息编写到Maven工程的配置文件，Maven就会自动下载并复制这些依赖项到项目中，无需自己导入jar包，管理jar!

场景2： 项目完成开发，我们想要打成war部署到服务器中，使用maven的构建命令可以快速打包！节省大量时间！

Maven软件工作原理模型图（了解）

2. Maven安装与配置

2.1. Maven安装

官网：Maven – Welcome to Apache Maven

安装条件： maven需要本机安装java环境、必需包含java_home环境变量！（否则cmd测试Maven版本的时候可能会提示找不到Java环境）

软件安装： 右键解压即可（绿色免安装）

软件结构：

bin：含有Maven的运行脚本

boot：含有plexus-classworlds类加载器框架

conf：含有Maven的核心配置文件

lib：含有Maven运行时所需要的Java类库

LICENSE、NOTICE、README.txt：针对Maven版本，第三方软件等简要介绍

2.2. Maven环境配置

配置MAVEN_HOME

win + i 键

配置Path

命令测试（cmd窗口）

mvn -v 
# 输出版本信息即可，如果错误，请仔细检查环境变量即可！

2.3. Maven功能配置

我们需要需改maven/conf/文件夹下的settings.xml配置文件，来修改maven的一些默认配置。我们主要休要修改的有三个配置：

1.依赖本地缓存位置（本地仓库位置）

2.maven下载镜像

3.maven选用编译项目的jdk版本

依赖本地缓存位置（本地仓库位置）

使用文本编辑工具打开，这里用的是：VS Code

把注释内的53行的内容复制到注释外

中间并改为自己的本地Maven仓库的地址

就是创建一个文件的，尽量不要中文路径和名字

我的是“F:\Develop\apache\LocalMavenWarehouse”

注意：

也可以自己不用创建文件夹即本地仓库，下载镜像时，如果检测到没有的话会自己自动创建一个的

maven下载镜像

在mirrors节点(标签)下添加中央仓库镜像 160行附近

<mirror>
    <id>alimaven</id>
    <name>aliyun maven</name>
    <url>http://maven.aliyun.com/nexus/content/groups/public/</url>
    <mirrorOf>central</mirrorOf>
</mirror>

maven选用编译项目的jdk版本

在profiles节点(标签)下添加jdk编译版本 268行附近

这是jdk17的

<profile>
    <id>jdk-17</id>
    <activation>
      <activeByDefault>true</activeByDefault>
      <jdk>17</jdk>
    </activation>
    <properties>
      <maven.compiler.source>17</maven.compiler.source>
      <maven.compiler.target>17</maven.compiler.target>
      <maven.compiler.compilerVersion>17</maven.compiler.compilerVersion>
    </properties>
</profile>

这是jdk8的

<profile>
    <id>jdk-8</id>
    <activation>
      <activeByDefault>true</activeByDefault>
      <jdk>1.8</jdk>
    </activation>
    <properties>
      <maven.compiler.source>1.8</maven.compiler.source>
      <maven.compiler.target>1.8</maven.compiler.target>
      <maven.compiler.compilerVersion>1.8</maven.compiler.compilerVersion>
    </properties>
</profile>

2.4. 基于IDEA创建Maven工程

打开IDEA编辑选项

Maven主路径为自己下载的Maven下载目录

用户设置文件为刚刚设置的setting文件位置

本地仓库也为刚刚创建的本地仓库文件 （无法修改就把右边的重写勾上）

3. 基于IDEA创建Maven工程

3.1. Maven工程的GAVP

Maven 中的 GAVP 四个核心属性是用来独特地定义和定位每一个 Maven 工程的，就像每个人都有自己的姓名和身份一样，每个 Maven 工程也有它独特的身份标识。以下是简化版的解释：

GroupID（组ID）：就像是家族姓氏，它代表了项目所属的组织或公司，通常按照反向域名的方式来命名，例如 com.example。这样做有助于避免不同组织之间的项目重名问题。
ArtifactID（工件ID）：如同个人名字，用于区分同一组织下的不同项目或模块，例如 my-app 或 awesome-service。每个 ArtifactId 在其对应的 GroupId 下必须是唯一的。
Version：相当于项目版本号，如 1.0.0，它反映了软件的不同迭代版本。当项目有更新或修复时，版本号会随之改变，这对于依赖管理和项目升级至关重要。
Packaging：好比是项目的“类型”，它定义了项目构建后产出的打包方式或格式，默认情况下通常是 jar（Java存档包），但也可能是 war（Web应用程序包）或其他类型，如 pom（仅用于聚合或继承的父项目）、ear（企业级应用归档）等。虽然 Packaging 不像前三者那样每次都需要明确指定，但它会影响 Maven 如何构建和处理项目的结果输出。

总结起来，在创建 Maven 工程时，我们需要指定 GroupId、ArtifactId 和 Version 这三个必不可少的信息，以便 Maven 能够在仓库中正确识别并管理项目。而 Packaging 属性虽然有默认值，但在某些特定场景下也需要适当地设置以满足项目构建的需求。这些属性一起构成了 Maven 中的项目坐标，使得各个项目之间可以方便且准确地相互引用和依赖。

3.2. IDEA构建Mave Java SE工程

创建工程之后，若第一次使用maven，或者使用的是新的本地仓库，idea右下角会出现以下进度条，表示maven正在下载相关插件，等待下载完毕，进度条消失即可

新建一个项目的Java-Maven项目结构

pom.xml文件样式

pakeging打包方式为自己手动写上去

<!-- 新增一列打包方式packaging -->
<packaging>jar</packaging>

添加Maven工程中依赖

打开这个网站：https://mvnrepository.com/

或者直接搜“Maven仓库”

以前是自己找jar包导入放在项目的lib文件夹中，有了Maven之后自己想要什么就可以在这里搜索

比如现在要一个连接MySQL的JDBC驱动jar包

要什么版本就点哪个版本（我这里选择的为8.0.25）

复制其文本

粘贴到pom文件中，并刷新一下（下面图片爆红就是因为没刷新）

如果是第一次导入依赖，需要创建一个dependencies的标签，并把复制的文本粘贴在dependencies的里面（这是XML语法规则）

点击右上角的刷新

此时Maven下就有了依赖项的（这不比以前导入jar包轻松多了）

3.3. IDEA构建Maven Java Web工程

3.3.1. 手动创建

在这之间创建一个Maven的Java SE工程（Maven_Web）

先创建一个项目Maven_Test

再到里面创建一个Java SE模块（Maven_Web）

但此时该模块中是没有Web资源文件夹的

修改pom.xml文件的打包方式

修改位置：项目（Maven_Web）下/pom.xml

<!-- 新增一列打包方式packaging -->
<packaging>war</packaging>

刷新后，查看项目结构（Maven_Web）有了Web资源路径可以设置

设置web资源路径和web.xml路径

按照上述提示进行操作

将Web.xml路径改为须和Web资源路径保持一致

此时，（Maven_Web）模块中有了Web

3.3.2. 插件创建

下载这个插件：JBLJavaToWeb

有蓝色的小圆点才创建成功

3.4. 将Maven的Web工程部署到tomcat

首先在webapp中创建一个前端H5文件

部署本地tomcat服务器

点击部署，选择对应的exploded工件，修改上下文

启动tomcat服务器，得到结果

3.5. Maven工程项目结构说明

Maven 是一款功能强大的构建自动化工具，它规定了一种标准的项目结构，使得开发者能够更高效地管理和维护项目的构建、依赖、测试与发布流程。针对 Maven Web 项目的文件夹结构及其各部分作用概述如下：

pom.xml：这是 Maven 项目的配置核心文件，其中定义了项目的依赖关系、构建过程、插件配置等相关信息。

- java：存储项目的 Java 源代码，按照包（package）结构进行组织，例如存放 Controller、Service、DAO 和 Model 等不同层次的业务逻辑代码。
- resources：存放项目运行所需的资源文件，包括但不限于日志配置文件（如 log4j.properties）、框架配置文件（如 spring-mybatis.xml）以及静态资源（如 CSS、JavaScript、图片等）。

src/main/webapp：

- WEB-INF：Web 应用的核心配置目录，包含 web.xml 文件（Java Web 应用的部署描述符），以及 classes 目录，用于存放编译后的 class 文件。
- index.html 或 index.jsp：Web 应用的首页或入口页面。

- java：存放项目中的单元测试代码，用来对项目中的各个模块进行独立测试。
- resources：存放与测试相关的资源文件，例如特定的测试环境配置文件等。

总结就是这样

|-- pom.xml                               # Maven 项目管理文件 
|-- src
    |-- main                              # 项目主要代码
    |   |-- java                          # Java 源代码目录
    |   |   `-- com/example/myapp         # 开发者代码主目录
    |   |       |-- controller            # 存放 Controller 层代码的目录
    |   |       |-- service               # 存放 Service 层代码的目录
    |   |       |-- dao                   # 存放 DAO 层代码的目录
    |   |       `-- model                 # 存放数据模型的目录
    |   |-- resources                     # 资源目录，存放配置文件、静态资源等
    |   |   |-- log4j.properties          # 日志配置文件
    |   |   |-- spring-mybatis.xml        # Spring Mybatis 配置文件
    |   |   `-- static                    # 存放静态资源的目录
    |   |       |-- css                   # 存放 CSS 文件的目录
    |   |       |-- js                    # 存放 JavaScript 文件的目录
    |   |       `-- images                # 存放图片资源的目录
    |   `-- webapp                        # 存放 WEB 相关配置和资源
    |       |-- WEB-INF                   # 存放 WEB 应用配置文件
    |       |   |-- web.xml               # Web 应用的部署描述文件
    |       |   `-- classes               # 存放编译后的 class 文件
    |       `-- index.html                # Web 应用入口页面
    `-- test                              # 项目测试代码
        |-- java                          # 单元测试目录
        `-- resources                     # 测试资源目录

总结来说，Maven 使用这种规范化的项目结构，帮助开发者更好地组织和管理项目，实现了开发、构建、测试和部署的全流程自动化。

4. 基于IDEA进行Maven工程构建

4.1. *lombok依赖

在Maven项目中为pom.xml文件添加Lombok依赖的步骤如下：

添加Lombok依赖

打开Maven项目的pom.xml文件，并在<dependencies>标签内添加Lombok的依赖。以下是具体的XML配置片段：

<dependencies>
    <!-- Lombok Dependency -->
    <dependency>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
        <version>1.18.24</version>
        <!-- 注意，对于仅编译时需要而运行时不需要的工具类库，可以添加optional或者scope为provided -->
        <scope>provided</scope>
    </dependency>
</dependencies>

上述示例中，Lombok的最新稳定版可能不是1.18.24，请根据实际情况查询Maven Central Repository以获取最新的版本号。

2. 注解处理器支持

由于Lombok是一个注解处理器，在某些IDE和构建工具中，为了使其在编译时生效，还需要确保IDE或构建工具支持注解处理器。对于Maven构建，一般情况下无需额外配置，但在IDE中使用Lombok时，例如在IntelliJ IDEA中，可能需要安装对应的Lombok插件以便IDE能正确解析和显示带有Lombok注解的类。

3. 使用Lombok注解

一旦添加了依赖并配置好环境，就可以在Java类中使用Lombok提供的各种注解，例如：

@Data：提供getter/setter、equals/hashCode、toString方法。
@NoArgsConstructor, @AllArgsConstructor, @RequiredArgsConstructor：生成构造函数。
@NonNull：用于非空检查和自动注入null检查的setter方法。
等等。

例如：

import lombok.Data;

@Data
public class User {
    private String name;
    private int age;
}

在上面的例子中，尽管User类没有显式定义任何getter和setter方法，但通过@Data注解，Lombok会在编译期间自动生成这些方法，从而简化代码。

4.2. 构建概念和构建过程

对于初学者来说，项目构建就像是制作蛋糕的过程。当你编写了一个Java程序或者Web应用，就像准备做蛋糕的各种食材——面粉（源代码）、糖（依赖库）、装饰品（资源文件）。而Maven这样的构建工具就像是厨房里的全能厨师机器人。

在IDEA中使用Maven构建项目，你可以这样理解：

源代码编译：就好比把面粉、鸡蛋等原料搅拌在一起做成面糊（即把.java文件编译成.class文件）。Maven会根据你在src/main/java目录下的源代码，利用预设或自定义的规则进行编译。
依赖管理：做蛋糕时需要添加糖和其他配料，对应编程时则是处理各种第三方库（比如Spring框架、数据库驱动等）。Maven通过pom.xml文件帮你自动获取并整合这些“配料”到项目中。
资源处理：静态资源的复制或处理，比如在src/main/resources下的配置文件会被正确地放置到最终的构建产物中，这就像把装饰蛋糕所需要的水果或糖霜准备好放在一边。
打包：当所有的东西都准备好了，Maven会像将面糊倒入模具然后烘烤一样，将编译好的class文件、资源文件以及其他必要的文件组合成一个整体，可能是WAR文件（Web应用归档）、JAR文件（Java归档）或其他类型的包，以便部署到服务器上运行。
部署：最后一步，就像把烤好的蛋糕放到展示柜里，Maven还能协助将构建好的应用程序部署到目标环境中，如应用服务器或云平台。

总的来说，使用IDEA配合Maven进行项目构建，是一种自动化流水线作业，它简化了从原始代码到可运行程序的整个复杂过程，让开发者无需手动一步步操作，大大提升了工作效率，并且有助于团队协作的一致性和可靠性。

4.3. 命令方式项目构建

命令	描述
mvn compile	编译项目，生成target文件
mvn package	打包项目，生成jar或war文件
mvn clean	清理编译或打包后的项目结构
mvn install	打包后上传到maven本地仓库
mvn deploy	只打包，上传到maven私服仓库
mvn site	生成站点
mvn test	执行测试源码

具体测试方法可以看尚硅谷Maven课程的P16-P19视频内容

链接传送门 --> 命令方式项目构建--尚硅谷

war包打包插件和jdk版本不匹配：pom.xml 添加以下代码即可

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

命令触发练习：

mvn 命令 命令

#清理
mvn clean
#清理，并重新打包
mvn clean package
#执行测试代码
mvn test

4.4. 可视化方式项目构建

注意：打包（package）和安装（install）的区别是什么

打包是将工程打成jar或war文件，保存在target目录下

安装是将当前工程所生成的jar或war文件，安装到本地仓库，会按照坐标保存到指定位置

具体测试方法可以看尚硅谷Maven课程的P22视频内容

链接传送门 --> 通过IDEA实现可视化构建

4.5. 构建插件、命令、生命周期命令之间关系

构建生命周期

我们发现一个情况！当我们执行package命令也会自动执行compile命令！

[INFO] --------------------------------[ jar ]---------------------------------
[INFO] 
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ mybatis-base-curd ---
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ mybatis-base-curd ---
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ mybatis-base-curd ---
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ mybatis-base-curd ---
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ mybatis-base-curd ---
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ mybatis-base-curd ---
[INFO] Building jar: D:\javaprojects\backend-engineering\part03-mybatis\mybatis-base-curd\target\mybatis-base-curd-1.0-SNAPSHOT.jar
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  5.013 s
[INFO] Finished at: 2023-06-05T10:03:47+08:00
[INFO] ------------------------------------------------------------------------

这种行为就是因为构建生命周期产生的！构建生命周期可以理解成是一组固定构建命令的有序集合，触发周期后的命令，会自动触发周期前的命令！！！构建周期作用：会简化构建过程例如：项目打包 mvn clean package即可。主要两个构建生命周期：

- 清理周期：主要是对项目编译生成文件进行清理包含命令：clean

默认周期：定义了真正构件时所需要执行的所有步骤，它是生命周期中最核心的部分包含命令：compile - test - package - install - deploy
插件、命令、周期三者关系（了解）周期→包含若干命令→包含若干插件使用周期命令构建，简化构建过程！最终进行构建的是插件！

5. 基于IDEA 进行Maven依赖管理

5.1. 依赖管理概念

Maven 依赖管理就像是一个自动化的图书馆管理员，对于 Java 开发项目来说，它管理着项目所需的“书籍”——也就是各种第三方库（jar包）和其他模块的依赖关系。就像图书馆员知道每本书的准确位置一样，Maven 通过读取项目中的 `pom.xml` 文件（即项目对象模型 Project Object Model），了解到项目需要用到哪些特定版本的依赖，并依据这些信息从 Maven 仓库（包括本地仓库、远程公共仓库或私有仓库）中获取对应的库文件。

开发者只需要在 pom.xml 中声明依赖的groupId（相当于作者或出版商）、artifactId（书名）以及version（图书版本），Maven 就能自动处理这些依赖的下载、更新及版本冲突解决工作。这样一来，不同模块之间的依赖可以得到妥善协调，不会因为依赖的不同版本导致项目无法正常编译或运行。

换言之，Maven 的依赖管理极大地简化了项目构建过程中的依赖管理环节，提升了开发效率，降低了因人为疏忽造成的错误风险，让开发者可以更专注于编码本身，而不必过多担忧底层依赖的问题。

5.2. Maven工程核心信息配置和解读（GAVP）

位置：pom.xml

<!-- 模型版本 -->
<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>

5.3. Maven工程依赖管理配置

位置：pom.xml

依赖管理和依赖添加

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

</dependencies>

依赖版本统一提取和维护

<!--声明版本-->
<properties>
  <!--命名随便,内部制定版本号即可！-->
  <junit.version>4.12</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>

这段XML配置片段来自于Maven的POM（Project Object Model）文件，主要用于统一管理项目依赖的版本。下面详细解释其作用和优点：

<properties>标签块：
这里自定义了在这个部分，您可以自定义一些属性值，这些属性可以在整个POM文件中复用。这里定义了junit.version属性为4.12，表示JUnit库的版本号；同时还定义了Maven默认的源码编码格式和报告输出编码格式。
这里自定义了junit.version属性为4.12，表示JUnit库的版本号；同时还定义了Maven默认的源码编码格式和报告输出编码格式。
统一管理依赖版本的好处：

- 集中式管理：将所有依赖的版本号集中在一个地方声明，便于查看和维护。当需要升级或降级某个依赖库时，只需修改对应属性值，无需在整个POM文件中查找并替换每一个依赖声明的地方。
- 一致性保证：避免由于手动填写版本号而导致的版本不一致问题，确保项目中所有使用到JUnit的地方都引用的是同一版本，降低版本冲突的风险。
- 易于更新：若未来项目决定升级JUnit至新版本，只需要更改一处${junit.version}的值，项目中所有依赖于JUnit的地方都会同步更新到新的版本。

使用${junit.version}引用版本号：
在 <dependencies> 部分的JUnit依赖配置中，通过 ${junit.version} 引用了之前在 <properties> 中声明的版本号。这样做实现了上述的集中管理与一致性保障。当Maven解析POM文件时，会将${junit.version}替换为实际的版本号4.12，从而完成对JUnit库的依赖引入。

总结起来，这种依赖版本的统一提取和维护方式，增强了项目的可维护性和管理便捷性，有助于团队协作和项目长期发展。

依赖添加具体流程差不多就是前面前面写过的样子，我直接原样copy下来

打开这个网站：https://mvnrepository.com/

或者直接浏览器搜“Maven仓库”，搜索的前面几个就是

以前是自己找jar包导入放在项目的lib文件夹中，有了Maven之后自己想要什么就可以在这里搜索

比如现在要一个连接MySQL的JDBC驱动jar包

要什么版本就点哪个版本（我这里选择的为8.0.25）

个人建议是看右边的usages使用数量，选择数量最多的，ヽ(￣▽￣)ﾉ

复制其文本

粘贴到pom文件中，并刷新一下（下面图片爆红就是因为没刷新）

如果是第一次导入依赖，需要创建一个dependencies的标签，并把复制的文本粘贴在dependencies的里面（这是XML语法规则）

点击右上角的刷新

此时Maven下就有了依赖项的（这不比以前导入jar包轻松多了）

5.4. 依赖范围

通过设置坐标的依赖范围(scope)，可以设置对应jar包的作用范围：编译环境、测试环境、运行环境

依赖范围	描述
compile	编译依赖范围，scope 元素的缺省值。使用此依赖范围的 Maven 依赖，对于三种 classpath 均有效，即该 Maven 依赖在上述三种 classpath 均会被引入。例如，log4j 在编译、测试、运行过程都是必须的。
test	测试依赖范围。使用此依赖范围的 Maven 依赖，只对测试 classpath 有效。例如，Junit 依赖只有在测试阶段才需要。
provided	已提供依赖范围。使用此依赖范围的 Maven 依赖，只对编译 classpath 和测试 classpath 有效。例如，servlet-api 依赖对于编译、测试阶段而言是需要的，但是运行阶段，由于外部容器已经提供，故不需要 Maven 重复引入该依赖。
runtime	运行时依赖范围。使用此依赖范围的 Maven 依赖，只对测试 classpath、运行 classpath 有效。例如，JDBC 驱动实现依赖，其在编译时只需 JDK 提供的 JDBC 接口即可，只有测试、运行阶段才需要实现了 JDBC 接口的驱动。
system	系统依赖范围，其效果与 provided 的依赖范围一致。其用于添加非 Maven 仓库的本地依赖，通过依赖元素 dependency 中的 systemPath 元素指定本地依赖的路径。鉴于使用其会导致项目的可移植性降低，一般不推荐使用。
import	导入依赖范围，该依赖范围只能与 dependencyManagement 元素配合使用，其功能是将目标 pom.xml 文件中 dependencyManagement 的配置导入合并到当前 pom.xml 的 dependencyManagement 中。

具体的操作方法可以看尚硅谷Maven课程的P27-P30视频内容

链接传送门--依赖范围

5.5. Maven工程依赖下载失败错误解决（重点）

原因：

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

下载依赖时出现网络故障或仓库服务器宕机等原因，导致无法连接至 Maven 仓库，从而无法下载依赖。
依赖项的版本号或配置文件中的版本号错误，或者依赖项没有正确定义，导致 Maven 下载的依赖项与实际需要的不一致，从而引发错误。
本地 Maven 仓库或缓存被污染或损坏，导致 Maven 无法正确地使用现有的依赖项。

解决方案：

检查网络连接和 Maven 仓库服务器状态。
确保依赖项的版本号与项目对应的版本号匹配，并检查 POM 文件中的依赖项是否正确。
清除本地 Maven 仓库缓存（lastUpdated 文件），因为只要存在lastupdated缓存文件，刷新也不会重新下载。本地仓库中，根据依赖的gav属性依次向下查找文件夹，最终删除内部的文件，刷新重新下载即可！

通过脚本快速清理lastUpdated文件

这是第四种方法，同时也比较方便、快速

具体步骤：

手动创建文件"clearLastUpdated.bat"，名字任意，但是后缀必须是bat，将以下内容复制到文件中

cls 
@ECHO OFF 
SET CLEAR_PATH=D: 
SET CLEAR_DIR=D:\maven-repository(本地仓库路径)
color 0a 
TITLE ClearLastUpdated For Windows 
GOTO MENU 
:MENU 
CLS
ECHO. 
ECHO. * * * *  ClearLastUpdated For Windows  * * * * 
ECHO. * * 
ECHO. * 1 清理*.lastUpdated * 
ECHO. * * 
ECHO. * 2 查看*.lastUpdated * 
ECHO. * * 
ECHO. * 3 退 出 * 
ECHO. * * 
ECHO. * * * * * * * * * * * * * * * * * * * * * * * * 
ECHO. 
ECHO.请输入选择项目的序号： 
set /p ID= 
IF "%id%"=="1" GOTO cmd1 
IF "%id%"=="2" GOTO cmd2 
IF "%id%"=="3" EXIT 
PAUSE 
:cmd1 
ECHO. 开始清理
%CLEAR_PATH%
cd %CLEAR_DIR%
for /r %%i in (*.lastUpdated) do del %%i
ECHO.OK 
PAUSE 
GOTO MENU 
:cmd2 
ECHO. 查看*.lastUpdated文件
%CLEAR_PATH%
cd %CLEAR_DIR%
for /r %%i in (*.lastUpdated) do echo %%i
ECHO.OK 
PAUSE 
GOTO MENU

注意：

要将这两行改为自己计算机上的本地Maven仓库的盘符位置和具体位置

括号只是提示，使用时记得删除掉

SET CLEAR_PATH=D: 
SET CLEAR_DIR=D:\maven-repository(本地仓库路径)

比如我的计算机，就应该是这样子的

SET CLEAR_PATH=F:
SET CLEAR_DIR=F:\Develop\apache\LocalMavenWarehouse

5.6. Maven工程Build构建配置

项目构建是一个自动化的过程，它将软件开发过程中的源代码、相关的依赖库、资源配置和其他必要文件整合起来，经过一系列步骤转化为可以运行的程序或者可以部署到服务器上的应用包。在Java开发环境中，Maven和Gradle是最常见的构建工具，它们都使用一个中心配置文件（对于Maven是pom.xml，对于Gradle是build.gradle）来定义构建过程的具体细节。

例如：

指定构建打包文件的名称，非默认名称
制定构建打包时，指定包含文件格式和排除文件
打包插件版本过低，配置更高版本插件

构建配置是在pom.xml / build标签中指定！

指定打包命名

<!-- 默认的打包名称：artifactid+verson.打包方式 -->
<build>
  <finalName>定义打包名称</finalName>
</build>

指定打包文件

如果在java文件夹中添加java类，会自动打包编译到classes文件夹下！

但是在java文件夹中添加xml文件，默认不会被打包！

默认情况下，按照maven工程结构放置的文件会默认被编译和打包！

除此之外、我们可以使用resources标签，指定要打包资源的文件夹要把哪些静态资源打包到 classes根目录下！

应用场景：mybatis中有时会将用于编写SQL语句的映射文件和mapper接口都写在src/main/java下的某个包中，此时映射文件就不会被打包，如何解决

<build>
    <!--设置要打包的资源位置-->
    <resources>
        <resource>
            <!--设置资源所在目录-->
            <directory>src/main/java</directory>
            <includes>
                <!--设置包含的资源类型-->
                <include>**/*.xml</include>
            </includes>
        </resource>
    </resources>
</build>

配置依赖插件

dependencies标签下引入开发需要的jar包！我们可以在build/plugins/plugin标签引入插件！

常用的插件：修改jdk版本、tomcat插件、mybatis分页插件、mybatis逆向工程插件等等！

<build>
  <plugins>
      <!-- java编译插件，配jdk的编译版本 -->
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <configuration>
          <source>1.8</source>
          <target>1.8</target>
          <encoding>UTF-8</encoding>
        </configuration>
      </plugin>
      <!-- tomcat插件 -->
      <plugin>
        <groupId>org.apache.tomcat.maven</groupId>
        <artifactId>tomcat7-maven-plugin</artifactId>
         <version>2.2</version>
          <configuration>
          <port>8090</port>
          <path>/</path>
          <uriEncoding>UTF-8</uriEncoding>
          <server>tomcat7</server>
        </configuration>
      </plugin>
    </plugins>
</build>

具体的操作方法可以看尚硅谷Maven课程的P34-P36视频内容

链接传送门--Maven工程构建