1.简介

Maven是一个Java项目管理和构建工具，他可以定义项目结构、项目依赖，并使用同意的方式进行自动化构建，是Java项目中不可缺少的工具。

2.Maven项目目录结构

该目录结构是事先约定好的！不可随意变更。

另外还有一个target目录（文件夹）专门用于存放构建操作输出的结果

2.1 约定目录结构的意义

Maven未来让Java项目构建的过程尽可能自动化完成，所以必须约定目录结构的作用。
例如：Maven执行编译操作，必须先去Java源程序目录读取Java源代码，然后执行编译，最后把编译结果存放在Target目录。

2.2 约定大于配置

Maven对于目录结构这个问题，没有采用配置的方法，而是基于约定。这回让我们在开发过程中比较方便。如果在每次创建Maven工程之后，还需要对各个目录的位置进行详细的配置，那肯定非常麻烦。
目前开发领域的技术趋势是：约定大于配置、配置大于编码。

3. POM.XML介绍

了解maven本质上就是了解pom.xml文件夹
一般我们在生成一个maven项目后，基础的pom.xml如下所示：

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"><!--版本相关--><modelVersion>4.0.0</modelVersion><!--本项目坐标信息(每个maven项目都会有唯一的坐标)--><!--通过这这三项组成的，通过坐标信息可以定位到具体的Jar包信息--><!--定位过程是仓库->镜像->找不到报错not found--><groupId>com.ztt</groupId> <!-- groupId 组织名称，一般是域名反写--><artifactId>untitled</artifactId> <!-- artifactId 项目名--><version>1.0-SNAPSHOT</version> <!-- version 版本名称--><properties><maven.compiler.source>8</maven.compiler.source><maven.compiler.target>8</maven.compiler.target><project.build.sourceEncoding>UTF-8</project.build.sourceEncoding></properties></project>

3.2 依赖引用

本质上就是：如何通过坐标信息引用jar包
maven项目在<dependencies></dependencies> 引入依赖（引入jar包）。

在pom.xml添加servlet的依赖

    <dependencies><!-- https://mvnrepository.com/artifact/javax.servlet/javax.servlet-api --><dependency><groupId>javax.servlet</groupId><artifactId>javax.servlet-api</artifactId><version>3.1.0</version></dependency></dependencies>

这时候这个依赖就已经添加进来了

3.3 属性管理

pom.xml属性管理一般用<properties> </properties> 包裹。
如下所示，同时下面我也介绍了几个常用的属性配置。

<!--属性变量--><properties><!--JDK版本--><maven.compiler.source>8</maven.compiler.source><maven.compiler.target>8</maven.compiler.target><!--编码--><project.build.sourceEncoding>UTF-8</project.build.sourceEncoding><!--这里也经常用于声明依赖的版本--><javax.servlet.version>3.1.0</javax.servlet.version></properties>

注意properties中经常用于生命依赖的版本，这样做的好处是可以帮助我们进行统一的版本管理。
具体操作如下。

4 Maven生命周期

4.1 经常遇到的生命周期

clean：默认是清除target目录中的所有文件，避免将历史版本打到新的包中造成一些不在预期中的问题。
process-resources：将资源文件src/main/resources下的文件复制到target/classes目录中。
compile：将src/main/java下的代码编译成 class 文件，也放到target/classes目录中。
process-test-resources：将资源文件src/test/resources下的文件复制到target/test-classes目录中。
test-compile：将src/test/java下的代码编译成 class 文件，也放到target/test-classes目录中。
test：运行单元测试并在target/surefire-reports中生成测试报告。
package：将资源文件、class文件、pom文件打包成一个jar/war包。
install：将生成的jar包推送到本地仓库中。
deploy：将生成的jar包推送到远程仓库中。

IDEA中打开Maven控制界面，查看生命周期

4.1 全部生命周期

1. Clean Lifecycle - 清理项目
pre-clean: 在清理之前执行的操作。
clean: 删除所有上一次构建生成的文件。

2. Default Lifecycle - 构建项目:
validate: 验证项目是正确的，所有必要的信息都已经准备就绪。
initialize: 初始化构建状态，例如设置属性。
generate-sources: 生成需要包含在编译中的源代码。
process-sources: 处理源代码，例如过滤源代码中的值。
generate-resources: 复制和生成资源文件到指定目录。
process-resources: 处理资源文件，例如替换资源中的占位符。
compile: 编译项目的源代码。
process-classes: 处理编译生成的类文件。
generate-test-sources: 生成测试源代码。
process-test-sources: 处理测试源代码。
generate-test-resources: 复制和生成测试资源文件。
process-test-resources: 处理测试资源文件。
test-compile: 编译测试源代码。
process-test-classes: 处理测试编译生成的类文件。
test: 使用单元测试框架运行测试。
prepare-package: 准备打包操作。
package: 将编译后的代码打包成可分发的格式，如JAR、WAR。
pre-integration-test: 在集成测试之前执行的操作。
integration-test:处理和部署包到可以运行集成测试的环境中。
post-integration-test: 在集成测试之后执行的操作。
verify: 运行任何检查以验证包是有效的。
install: 安装包到本地仓库，使其可以作为其他项目的依赖。
deploy: 将最终的包复制到远程仓库，供其他开发人员和项目使用。

3.Site Lifecycle - 生成项目站点
pre-site: 在生成项目站点之前执行的操作。
site: 生成项目报告和文档。
post-site: 在生成项目站点之后执行的操作。
site-deploy: 将生成的站点部署到服务器上。

5.依赖范围（Scope）

依赖作用范围一般在<scope></scope>中设置
Maven的依赖范围包括：编译、测试、运行\打包(刚入门可以把运行和打包理解成一个)
编译：只在main\java的中有效
测试：只在main\test中有效
运行\打包：项目生成war、jar包时，在运行过程中使用到该依赖。

作用范围的建议

1. 所有的Scope都设置成compile也不会影响功能的正常运行，同时90%以上的依赖都会使用compile
2. 每个依赖会有自己默认的scope，同时maven也会对依赖的scope自动补全，所以建议用官方提供的scope也没毛病。

6. 依赖传递

在Maven中，依赖可以传递的，假设存在三个项目，项目A、项目B、项目C。假设C依赖B，B依赖A，那么我们可以根据Maven项目依赖的特征推断出项目C也依赖项目A。

6.1 依赖冲突

依赖冲突通常发生在项目中使用了多个库，而这些库又依赖于相同库的不同版本时。这种情况可能导致构建失败或运行时错误，因为Java运行时环境要求所有类库的版本必须一致。下面是一个具体的例子来说明依赖冲突：

假设你正在开发一个Java Web应用程序，并且你的项目有以下依赖关系：

你的项目直接依赖于LibraryA，版本1.0。
LibraryA又依赖于CommonLib，版本1.5。
同时，你的项目还直接依赖于LibraryB，版本2.0。
而LibraryB也依赖于CommonLib，但需要版本2.0。

这里的依赖关系可以表示为：

在这个例子中，CommonLib的两个不同版本（1.5和2.0）被引入到项目中，这将导致依赖冲突。Maven会尝试根据其依赖解析策略来解决这个冲突，但如果没有明确指定版本，可能会导致以下问题：

1. 构建失败：Maven可能无法决定使用哪个版本的CommonLib，导致构建失败。
2. 运行时错误：如果Maven选择了一个版本，但在运行时环境中使用了另一个版本的CommonLib，可能会导致NoClassDefFoundError或ClassNotFoundException等错误。

6.2 解决依赖冲突

6.2.1 最近依赖者优先

Maven的依赖调解原则，通常被称为"最近依赖者优先"或"第一声明者原则"（First Declaration Rule），是Maven处理传递性依赖冲突时使用的一种策略。这个原则确保了依赖冲突可以通过一个简单的规则来解决，从而避免了复杂的版本冲突问题。

第一声明者原则的工作原理：
依赖树的构建：Maven首先构建项目的依赖树，包括直接依赖和所有间接依赖。

冲突检测：在构建依赖树的过程中，Maven会检测到多个依赖项可能依赖于同一个库的不同版本。

选择依赖版本：当检测到版本冲突时，Maven会选择依赖树中距离项目最近的依赖项指定的版本。换句话说，它会选择第一个声明该库依赖的依赖项的版本。

忽略后续声明：在依赖树中，任何后续声明的相同库的不同版本将被忽略，即使它们可能是更新的或更低的版本。

6.2.2 路径近者优先原则

路径近者优先原则（Shortest Path Rule）是Maven处理依赖冲突时使用的另一种策略，它与第一声明者原则有相似之处，但更侧重于依赖路径的长度。这个原则确保了在多个依赖项指向同一个库的不同版本时，Maven选择路径最短的依赖版本。

路径近者优先原则的工作原理：
依赖树构建：Maven构建项目的依赖树，包括直接依赖和间接依赖。

冲突检测：在构建依赖树的过程中，Maven检测到多个依赖项可能依赖于同一个库的不同版本。

最短路径选择：当检测到版本冲突时，Maven会选择依赖路径最短的依赖项指定的版本。依赖路径是指从项目到依赖项的直接距离。

忽略长路径声明：即使长路径上的依赖项声明了更新或更低的版本，Maven也会忽略它，因为根据路径近者优先原则，它不是最优选择。

6.3 依赖排除

依赖排除是Maven处理依赖冲突的一种常用方法。以下是如何进行依赖排除的一个具体例子：

假设你的项目直接依赖于两个库：LibraryA 和 LibraryB。但是，LibraryA 和 LibraryB 都间接依赖于同一个库 CommonLib，并且它们依赖的 CommonLib 版本不同。为了解决这个冲突，你可以选择排除一个版本的 CommonLib，并显式地声明你需要的版本作为直接依赖。

以下是pom.xml文件中的依赖配置示例：

<dependencies><!-- 直接依赖LibraryA --><dependency><groupId>com.example</groupId><artifactId>LibraryA</artifactId><version>1.0</version><!-- 排除LibraryA中对CommonLib 1.5的依赖 --><exclusions><exclusion><groupId>com.common</groupId><artifactId>CommonLib</artifactId></exclusion></exclusions></dependency><!-- 直接依赖LibraryB --><dependency><groupId>com.example</groupId><artifactId>LibraryB</artifactId><version>2.0</version><!-- 排除LibraryB中对CommonLib 2.0的依赖 --><exclusions><exclusion><groupId>com.common</groupId><artifactId>CommonLib</artifactId></exclusion></exclusions></dependency><!-- 显式声明CommonLib的版本，确保使用一致的版本 --><dependency><groupId>com.common</groupId><artifactId>CommonLib</artifactId><version>1.5</version> <!-- 假设我们决定使用1.5版本 --></dependency></dependencies><!-- ... 其他配置 ... -->

在这个例子中，我们首先排除了 LibraryA 和 LibraryB 中对 CommonLib 的依赖。然后，我们添加了一个直接依赖项，指定了 CommonLib 的版本为1.5。这样，无论 LibraryA 和 LibraryB 依赖的是 CommonLib 的哪个版本，Maven都会使用我们显式声明的版本1.5。

通过这种方式，你可以控制项目中使用的依赖项的版本，避免由于依赖传递带来的版本冲突问题。

7. 聚合项目

Maven聚合项目（也称为多模块项目或父项目）是一种项目组织方式，它允许你将一个大项目分解成多个小的、可管理的模块。每个模块可以独立构建和维护，同时仍然可以作为一个整体来构建和分发。

对于项目开发，聚合项目有以下好处
模块化：将一个大项目分解成多个模块，有助于更好地组织代码，每个模块负责特定的功能或组件。
重用性：模块化使得代码可以在不同项目中重用，因为它们可以作为独立的组件进行构建和部署。
并行开发：在多模块项目中，不同的团队可以同时在不同的模块上工作，这有助于提高开发效率和加快开发速度。
依赖管理：父项目可以使用部分来统一管理所有子模块的依赖版本，确保依赖的一致性。

作为聚合项目，其父项目应该

1. 删除src,聚合项目的父项目不承担代码，只是作为子项目的管理
2. <packaging></packaging> 一般为jar或者war,但是作为父项目，其不是一个具体的包，固其中pom.xml中的应进行<packaging>pom</packaging>设置。
3. 利用pom.xml中的 <modules> </modules>管理子工程