作用
Maven不仅可以进行依赖管理的自动化，还可以自动化实现编译，打包，发布，等，也被成为构建流程
生命周期（lifecycle）
构成
Maven生命周期本身可以看做一个集合，在这个集合中包含了一系列阶段（phase）。也就是说Maven的生命周期由一系列阶段（phase）构成
但是话又说回来phase又是什么，Maven把打包的项目分为了很多个阶段，这个阶段就直接用了phase来表示，因为我们的需求是不同的，所以整个项目应该被打包到怎么个程度也是不同的，一个很形象的例子就是比如C语言的编译过程一样
C语言的编译有下面四个过程：
- 预处理
- 编译
- 汇编
- 链接
Maven的打包阶段就像这几个过程一样，我们可以指定打包到那种程度，就像C语言我们让他编译到哪个程度，比如我们要编译到汇编的这个过程，不需要链接。这样就像我们运行mvn package，整个打包就会打包到package的程度。C语言编译的这四个过程就就如phase一样。
default生命周期
这里我们可以来看下最常用的default周期是怎么样的
| 阶段名称 | 描述 |
|---|---|
| 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 | 将最终的包复制到远程仓库，供其他开发者和项目使用。 |
如果我们运行mvn package，Maven就会执行default生命周期，它会从开始一直运行到package这个phase为止
如果我们运行mvn compile，Maven也会执行default生命周期，但这次它只会运行到compile
clean生命周期
当然我们不止default周期，还有很多周期，这里还介绍一下clean周期
- pre-clean - 这是
clean生命周期的第一个阶段，用于执行任何在真正清理之前需要完成的工作。这个阶段可以用来做一些准备工作，比如备份文件或者检查是否有足够的权限来执行清理操作。 - clean - 这个阶段是
clean生命周期的核心，它负责实际的清理工作。在这个阶段，Maven 会删除之前构建过程中生成的所有文件，例如编译生成的.class文件、测试结果、打包生成的 JAR 或 WAR 文件等。目的是清除所有构建产物，以便下一次构建时能从干净的状态开始。 - post-clean - 这是
clean生命周期的最后一个阶段，用于执行清理之后需要完成的任务。这个阶段可以用来进行一些清理后的收尾工作，比如删除临时文件或者发送清理完成的通知。
更复杂的例子是指定多个phase，例如，运行mvn clean package，Maven先执行clean生命周期并运行到clean这个phase，然后执行default生命周期并运行到package这个phase，实际执行的phase如下：
- pre-clean
- clean （注意这个clean是phase）
- validate （开始执行default生命周期的第一个phase）
- initialize
- ...
- prepare-package
- package
在实际开发过程中，经常使用的命令有：
mvn clean：清理所有生成的class和jar；
mvn clean compile：先清理，再执行到compile；
mvn clean test：先清理，再执行到test，因为执行test前必须执行compile，所以这里不必指定compile；
mvn clean package：先清理，再执行到package。
phase绑定的操作：goal
每一个phase都有一个操作，但是这不代表说是phase在操作，而是里面包含的一个goal在操作，phase的下边可以绑定很多的goal，这样就使得phase能按照我们自己的想法来DIY phase的操作。这样也就是说phase其实也就是一个包含了goal的集合。
这个时候我们其实就能有一个具体的框架了
- Maven的流程框架中包含了很多个lifecycle
- 每一个的lifecycle都包含了很多个phase
- 每一个phase中又包含了很多个goal
- 最后goal包含的就是操作的代码
自定义插件
我们前面说到，phase绑定的操作其实是在goal中的，很多时候自带的phase是无法满足我们的需求的，这个时候我们就需要能自定义goal，这个就是自定义插件解决的问题
自定义插件的配置
一般来说，这样一个goal的配置是在pom.xml去配置的，这个文件都在你项目之中的
1. 引入插件 (maven-shade-plugin)
在 Maven 中，我们可以通过 <build><plugins> 标签来添加插件，这种插件声明告诉 Maven，我们在构建过程中需要一些标准操作以外的额外处理。
如，maven-shade-plugin 是一个非标准插件，主要作用是将项目的所有依赖和源代码打包成一个“胖 jar”（fat jar）。这种 jar 文件包含项目的所有依赖，可以在任何支持 Java 的系统上直接运行。
<build><plugins><plugin><groupId>org.apache.maven.plugins</groupId><artifactId>maven-shade-plugin</artifactId><version>3.2.1</version><!-- 插件的基本信息，指定 Maven 要引入的插件 --></plugin></plugins>
</build>2. 设置插件的执行阶段和目标 (<executions>)
<executions> 这个标签就定义了在哪个phase中实现我们的操作。每个阶段对应一组任务，比如 clean、compile、test、package、install 等。package 阶段是将项目打包成 jar 文件的阶段。
- 执行阶段 (phase) ：我们将插件的执行阶段设定为
package，这样当执行mvn package命令时，Maven 会在打包阶段运行maven-shade-plugin。 - 执行目标 (goals) ：
<goal>shade</goal>指定了这个插件在package阶段的主要任务是将所有依赖打包进 jar 文件中。shade是maven-shade-plugin的一个默认目标，用于合并依赖项并生成胖 jar。
<executions><execution><phase>package</phase> <!-- 在 package 阶段执行 --><goals><goal>shade</goal> <!-- shade 目标用于合并依赖 --></goals></execution>
</executions>3. 配置插件 (<configuration>)
大部分自定义插件需要额外的配置项。maven-shade-plugin 的配置项主要用于指定打包时的行为。下面是该插件常见的几个配置项：
(a) <transformers>：用于修改 jar 文件的内容，尤其是资源文件的合并和 manifest 文件的配置。
在 jar 文件中，Manifest.mf 文件存放着关于 jar 文件的元数据信息，比如版本号、开发者信息等。在可执行 jar 文件中，Manifest.mf 的 Main-Class 字段决定了该 jar 的入口类（main）。配置 maven-shade-plugin 的 <transformers> 标签，并使用 ManifestResourceTransformer，可以指定 jar 的主类。
(b) <mainClass>：指定主类
<mainClass> 用于定义应用程序启动时所使用的主类。即当使用 java -jar your-app.jar 启动 jar 文件时，JVM 会从 <mainClass> 指定的类中寻找 public static void main(String[] args) 方法作为入口。
<configuration><transformers><transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer"><mainClass>com.itranswarp.learnjava.Main</mainClass> <!-- 主类 --></transformer></transformers>
</configuration>将这些元素组合在一起，我们得到了一个完整的 maven-shade-plugin 配置示例：
<build><plugins><plugin><groupId>org.apache.maven.plugins</groupId><artifactId>maven-shade-plugin</artifactId><version>3.2.1</version><executions><execution><phase>package</phase> <!-- package 阶段执行 --><goals><goal>shade</goal> <!-- shade 目标生成胖 jar --></goals><configuration><transformers><transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer"><mainClass>com.itranswarp.learnjava.Main</mainClass> <!-- 主类指定 --></transformer></transformers></configuration></execution></executions></plugin></plugins>
</build> 注意，Maven自带的标准插件例如compiler是无需声明的，只有引入其它的插件才需要声明。
下面列举了一些常用的插件：
- maven-shade-plugin：打包所有依赖包并生成可执行jar；
- cobertura-maven-plugin：生成单元测试覆盖率报告；
- findbugs-maven-plugin：对Java源码进行静态分析以找出潜在问题。
自己实践使用maven-shade-plugin创建可执行jar遇到的问题日志
build的位置
注意整个<build>标签是放在<project>里面就行
<groupId>的命名
org.apache.maven.plugins这个id是maven官方的插件所以我们不用改
Main的路径
<transformers><transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer"><mainClass>com.example.Main</mainClass> </transformer>
</transformers>
每个人的main函数都不一样，但是只要指定对main函数的类就行
如果这段代码有错的话你执行可执行文件会报错：.jar中没有主清单属性
使用mvn 指令后可执行文件的位置
我在项目的根目录执行完mvn clean package后，整个输出都会在根目录下的target文件中，直接执行.jar文件就行
