本文主要是介绍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包的内容
这篇关于maven 以及插件重写的一些思考的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!