maven 以及插件重写的一些思考

先简单了解一下maven：
https://maven.org.cn/maven-features.html
下面是maven的各个阶段的一些信息，由于已经存在，直接查看GPT的解释：

maven的主要阶段包含 install、test、deploy、package 等。这些阶段属于 Maven 的
default（或 build）生命周期。下面是对这些关键阶段的详细介绍：

1. validate

• 作用：验证项目是否正确且所有必要的信息是否可用。
• 用途：确保 POM 文件中的配置正确、必要的参数已经设置等。

2. compile

• 作用：编译项目的主源代码。
• 用途：将 src/main/java 目录下的 Java 源文件编译成 .class 文件，并放在 target/classes 目录中。

3. test-compile

• 作用：编译测试源代码。
• 用途：将 src/test/java 目录下的测试源文件编译成 .class 文件。

4. test

• 作用：运行测试代码。
• 用途：使用测试框架（如 JUnit）运行编译后的测试代码。测试结果会生成在 target/surefire-reports 目录中。
• 注意：测试阶段只会运行那些标记为测试的代码，并确保代码逻辑符合预期。

5. package

• 作用：将编译后的代码打包成可分发的格式。
• 用途：生成如 JAR、WAR 或其他可分发格式的文件。打包后的文件通常位于 target 目录中。

6. verify

• 作用：运行任何检查，验证包是否有效且符合质量标准。
• 用途：在 test 和 package 之后执行的额外检查，确保生成的包满足要求。

7. install

• 作用：将生成的包安装到本地 Maven 仓库。
• 用途：将包（如 JAR 或 WAR）复制到本地仓库，以便其他本地 Maven 项目可以使用该包作为依赖。默认情况下，本地仓库位于用户主目录下的 .m2/repository 目录。

8. deploy

• 作用：将最终的包复制到远程仓库。
• 用途：将包发布到远程 Maven 仓库（如 Maven Central 或企业内部的私有仓库），以便其他开发者或项目可以使用这个包。通常在 CI/CD 流程中使用这个阶段来自动化发布过程。

生命周期阶段的顺序和依赖关系

• 依赖顺序：当你运行 mvn install 时，Maven 会自动执行从 validate 到 install 之间的所有阶段。
• 组合调用：例如，mvn deploy 会执行 validate、compile、test、package、verify、install 和 deploy
  这些阶段。

实际使用示例 假设你在命令行中运行 mvn install，Maven 会按顺序执行以下阶段：

1. validate：检查项目是否配置正确。
2. compile：编译主代码。
3. test-compile：编译测试代码。
4. test：运行测试。
5. package：将项目打包成 JAR 或 WAR 文件。
6. install：将打包文件安装到本地 Maven 仓库。

运行 mvn deploy 会在执行上述阶段后，将包部署到远程仓库。

通过这种方式，Maven 提供了一个统一的构建和发布流程，帮助开发者有效地管理项目的整个生命周期。

我们最近基于自己的项目需要重构maven的打包逻辑，即服用之前的编译等逻辑但是手动修改maven的package插件，使用@Mojo注解将complie好的类进行

Maven plugins can be written in Java or any of a number of scripting
languages. Plugins consists of one or more Mojos, each one being the
implementation for one of the plugin’s goals.
https://maven.apache.org/developers/mojo-api-specification.html

关于@Mojo的一些参数之类的不过多赘述，在互联网上可以找到很多的资料，想记录一些之前没有思考过的知识点：
1.maven在deploy的时候会对子maven也进行deploy然后会对自己进行deploy，在我们之前的实践中，存在这样一种情况，正常情况下，假如存在这样一个maven项目：
parent-project
│ pom.xml
│
├── module-a
│ └── pom.xml
│
├── module-b
│ └── pom.xml
│
└── module-c
└── pom.xml

如果我们正常的执行maven的deploy逻辑，实际上会先对module abc分别进行deploy然后会对parent- project进行一个整体的deploy逻辑，得到四个jar包，但是我们因为一些业务逻辑想要对abc本身打包成一个a.jar 然后对module abc的依赖进行一个整体的打包得到一个dependency.jar，然后对于这两个jar
那怎么实现这个呢？先了解一下assembly.xml
https://maven.apache.org/guides/mini/guide-assemblies.html

assembly.xml 是 Maven Assembly 插件的配置文件，用于定义如何将项目的构件（如 JAR、WAR 文件）和依赖项、资源文件等打包成一个分发包（如 ZIP、TAR.gz 等）。这个文件允许我们自定义打包的内容和结构，以便将整个项目及其依赖项一起分发。
举个例子

<assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2 
                              http://maven.apache.org/xsd/assembly-1.1.2.xsd">

    <!-- 定义这个 assembly 的唯一标识符，用于生成的文件名的一部分 -->
    <id>distribution</id>

    <!-- 定义输出的打包格式，这里指定为 ZIP 格式 -->
    <formats>
        <format>zip</format>
    </formats>

    <!-- 是否在生成的包中包含一个顶级目录 -->
    <includeBaseDirectory>true</includeBaseDirectory>

    <!-- 定义文件集，指定要包含在包中的目录和目标路径 -->
    <fileSets>
        <fileSet>
            <!-- 要打包的源文件目录 -->
            <directory>src/main/resources</directory>
            <!-- 在生成的包中的输出路径 -->
            <outputDirectory>/resources</outputDirectory>
        </fileSet>
    </fileSets>

    <!-- 定义依赖项集，指定要包含的依赖项及其在包中的目标路径 -->
    <dependencySets>
        <dependencySet>
            <!-- 依赖项在生成的包中的输出路径 -->
            <outputDirectory>/lib</outputDirectory>
            <!-- 是否解压依赖项 -->
            <unpack>false</unpack>
            <!-- 包含的依赖项的范围，例如 runtime、compile、test 等 -->
            <scope>runtime</scope>
        </dependencySet>
    </dependencySets>

    <!-- 定义单个文件，指定要包含的文件和目标路径 -->
    <files>
        <file>
            <!-- 要打包的单个文件 -->
            <source>README.md</source>
            <!-- 在生成的包中的输出路径 -->
            <outputDirectory>/</outputDirectory>
        </file>
    </files>
</assembly>

根据上面的逻辑，我们可以得到哪些文件会被打包，另外由于我们重写了repackage插件，我们就可以自由的控制打包的jar包的内容