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 会按次序执行以下阶段：
[*]validate：检查项目是否设置精确。
[*]compile：编译主代码。
[*]test-compile：编译测试代码。
[*]test：运行测试。
[*]package：将项目打包成 JAR 或 WAR 文件。
[*]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包的内容
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]