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 等）。这个文件允许我们自定义打包的内容和布局，以便将整个项目及其依赖项一起分发。
举个例子

1. <assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2"
2.           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
3.           xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
4.                               http://maven.apache.org/xsd/assembly-1.1.2.xsd">
6.     <!-- 定义这个 assembly 的唯一标识符，用于生成的文件名的一部分 -->
7.     <id>distribution</id>
9.     <!-- 定义输出的打包格式，这里指定为 ZIP 格式 -->
10.     <formats>
11.         <format>zip</format>
12.     </formats>
14.     <!-- 是否在生成的包中包含一个顶级目录 -->
15.     <includeBaseDirectory>true</includeBaseDirectory>
17.     <!-- 定义文件集，指定要包含在包中的目录和目标路径 -->
18.     <fileSets>
19.         <fileSet>
20.             <!-- 要打包的源文件目录 -->
21.             <directory>src/main/resources</directory>
22.             <!-- 在生成的包中的输出路径 -->
23.             <outputDirectory>/resources</outputDirectory>
24.         </fileSet>
25.     </fileSets>
27.     <!-- 定义依赖项集，指定要包含的依赖项及其在包中的目标路径 -->
28.     <dependencySets>
29.         <dependencySet>
30.             <!-- 依赖项在生成的包中的输出路径 -->
31.             <outputDirectory>/lib</outputDirectory>
32.             <!-- 是否解压依赖项 -->
33.             <unpack>false</unpack>
34.             <!-- 包含的依赖项的范围，例如 runtime、compile、test 等 -->
35.             <scope>runtime</scope>
36.         </dependencySet>
37.     </dependencySets>
39.     <!-- 定义单个文件，指定要包含的文件和目标路径 -->
40.     <files>
41.         <file>
42.             <!-- 要打包的单个文件 -->
43.             <source>README.md</source>
44.             <!-- 在生成的包中的输出路径 -->
45.             <outputDirectory>/</outputDirectory>
46.         </file>
47.     </files>
48. </assembly>

复制代码

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

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。