Maven

为什么 maven-archetype-plugin 可以直接简写为 archetype 使用？

这个规则是 Maven 内部机制和插件命名规范共同作用的结果，具体规定在以下两个地方：

• Maven 的核心内置配置 (Built-in Configuration)：规定了“去哪里找”
• 插件本身的元数据 (Plugin Metadata)：规定了“我叫什么”

当你执行一个命令，比如 mvn archetype:generate 时，Maven 并不知道 archetype 是什么。它会执行一个叫做“前缀解析”的查找过程，来把这个简短的前缀（prefix）映射到一个完整的插件坐标org.apache.maven.plugins:maven-archetype-plugin (groupId:artifactId)。

遵循以下规则：

• 查找默认的插件组 (Default Plugin Groups)
  Maven 的核心配置中，预先定义了一个默认的插件组列表 (pluginGroups)。其中最重要的、硬编码在程序里的就是：org.apache.maven.plugins
• 若插件元数据文件定义了<goalPrefix> 如果插件的元数据文件（通常是 META-INF/maven/plugin.xml）中定义了 <goalPrefix>，Maven 会直接使用这个前缀来匹配插件。例如：

 1<project>
 2  ...
 3  <build>
 4    ...
 5    <plugins>
 6      ...
 7      <plugin>
 8        <artifactId>maven-plugin-plugin</artifactId>
 9        <version>3.15.1</version>
10        <configuration>
11          ...
12          <goalPrefix>somePrefix</goalPrefix>
13        </configuration>
14      </plugin>
15    </plugins>
16  </build>
17</project>

上述配置将允许用户通过前缀 somePrefix 来引用你的插件，如下例所示：

1mvn somePrefix:goal

• 根据命名规范进行匹配 当 Maven 拿到一个前缀（比如 archetype）时，它会尝试在这个默认的插件组 (org.apache.maven.plugins) 中寻找一个符合命名规范的 artifactId。匹配的模式主要有两种：
  • maven-${prefix}-plugin (官方插件最常用的模式)
  • ${prefix}-maven-plugin 同样的道理也适用于其他官方插件：
  • mvn compiler:compile -> compiler 被解析为 maven-compiler-plugin
  • mvn surefire:test -> surefire 被解析为 maven-surefire-plugin

在哪里可以自定义插件组(Plugin Groups)？

可以在 settings.xml 文件中扩展插件组列表 (pluginGroups)，添加 <pluginGroups> 标签，把常用的第三方插件的 groupId 加进去。

例如： 如果你经常使用 Spring Boot 的插件，它的 groupId 是 org.springframework.boot。你可以这样配置：

1<settings>
2  ...
3  <pluginGroups>
4    <pluginGroup>org.springframework.boot</pluginGroup>
5  </pluginGroups>
6  ...
7</settings>

配置好之后，原本需要输入完整命令：

1mvn org.springframework.boot:spring-boot-maven-plugin:run

现在就可以简写为：

1mvn spring-boot:run

Maven 会在默认的 org.apache.maven.plugins 中查找失败后，继续在你配置的 org.springframework.boot 组中查找，并成功匹配到 spring-boot-maven-plugin

是的，绝对是。

Maven 的生命周期（Lifecycle）及其包含的阶段（Phase）的定义、顺序和骨架，是 Maven 框架最核心、最基础的组成部分。可以这样理解：

生命周期和阶段 (Lifecycle & Phase)：是 Maven 定义的一套标准化的流程和步骤（比如先编译、再测试、后打包）。这个“流程图”是内置在 Maven 核心中的，它规定了“做什么”以及“按什么顺序做”。 插件 (Plugin)：是具体“干活的人”。它们负责执行每个步骤的实际工作。 所以，Maven 核心提供了不变的、标准化的构建流程框架，而插件则提供了可变的、可配置的具体实现。这种分离正是 Maven 强大和灵活的关键。

参考：Lifecycle Reference

A. default 生命周期（最重要的构建生命周期）

1. validate: 验证项目是否正确以及所有必需的信息是否可用。
2. initialize: 初始化构建状态，例如设置属性。
3. generate-sources: 生成任何需要包含在编译过程中的源代码。
4. process-sources: 处理源代码，例如过滤值。
5. generate-resources: 生成需要打包到项目中的资源文件。
6. process-resources: 将资源文件复制并处理到目标目录，准备打包。
7. compile: 编译项目的源代码。
8. process-classes: 对编译生成的文件进行后处理，例如字节码增强。
9. generate-test-sources: 生成测试用的源代码。
10. process-test-sources: 处理测试源代码。
11. generate-test-resources: 生成测试用的资源文件。
12. process-test-resources: 将测试资源文件复制并处理到测试目标目录。
13. test-compile: 编译测试源代码。
14. process-test-classes: 对测试编译生成的文件进行后处理。
15. test: 使用合适的单元测试框架（如 JUnit）运行测试。
16. prepare-package: 在打包前进行准备工作。
17. package: 将编译后的代码打包成可分发的格式，如 JAR、WAR 等。
18. pre-integration-test: 在集成测试前进行准备。
19. integration-test: 运行集成测试。
20. post-integration-test: 在集成测试后进行清理。
21. verify: 运行检查以验证包是否有效并符合质量标准。
22. install: 将包安装到本地仓库，供本地其他项目依赖。
23. deploy: 将最终的包复制到远程仓库，与其他开发者或项目共享。

B. clean 生命周期

用于清理上一次构建生成的文件。

主要阶段：

1. pre-clean: 在实际清理前执行一些操作。
2. clean: 移除上一次构建生成的所有文件（通常是 target 目录）。
3. post-clean: 在实际清理后执行一些操作。

C. site 生命周期

用于生成和部署项目站点（项目文档、报告等）。

主要阶段：

1. pre-site: 在生成站点文档前执行一些操作。
2. site: 生成项目的站点文档。
3. post-site: 在生成站点文档后执行一些操作，例如进行打包。
4. site-deploy: 将生成的站点文档部署到指定的服务器。

方式一：默认绑定 (由打包方式 <packaging> 决定)

这是 Maven “约定大于配置”理念的体现。Maven 会根据你在 pom.xml 中设置的打包方式（<packaging>，如 jar, war, pom），为核心的生命周期阶段绑定一套默认的插件目标。

• 如果你的 pom.xml 中有 <packaging>jar</packaging> (或者不写，因为 jar 是默认值)。
• Maven 会自动将 maven-compiler-plugin 的 compile 目标绑定到 compile 阶段，将 maven-surefire-plugin 的 test 目标绑定到 test 阶段，将 maven-jar-plugin 的 jar 目标绑定到 package 阶段。
• 你完全不需要任何配置，执行 mvn package 时，编译、测试、打包工作就会自动进行。

参考：Built-in Lifecycle Bindings

方式二：插件的“默认阶段绑定” (Default Phase Binding)

有些为特定目的而设计的插件（比如代码生成、资源处理），其作者已经预见到了它最常见的用例。因此，在插件本身的元数据中，开发者已经定义了它的默认绑定阶段。

例如，Modello 插件默认将其目标 modello:java 绑定到 generate-sources 阶段，我们只需要在 pom.xml 中添加如下配置：

 1 <plugin>
 2   <groupId>org.codehaus.modello</groupId>
 3   <artifactId>modello-maven-plugin</artifactId>
 4   <version>1.8.1</version>
 5   <executions>
 6     <execution>
 7       <configuration>
 8         <models>
 9           <model>src/main/mdo/maven.mdo</model>
10         </models>
11         <version>4.0.0</version>
12       </configuration>
13       <goals>
14         <goal>java</goal>
15       </goals>
16     </execution>
17   </executions>
18 </plugin>

您可能想知道为什么要使用 <executions> 元素。这样您就可以在需要时使用不同的配置多次运行同一个目标。还可以给单独的执行赋予一个 ID，这样在继承或应用配置文件时，就可以控制目标配置是被合并还是被转化为额外的执行。

方式三：手动绑定 (Manual Binding)

如果你需要更细粒度的控制，或者想要在特定阶段执行某个插件的目标，你可以手动绑定插件目标到生命周期阶段。
例如，假设有一个目标 display:time，它能在命令行中回声显示当前时间，你希望它在 process-test-resources 阶段运行，以显示测试何时开始。可以这样配置

 1 <plugin>
 2   <groupId>com.mycompany.example</groupId>
 3   <artifactId>display-maven-plugin</artifactId>
 4   <version>1.0</version>
 5   <executions>
 6     <execution>
 7       <phase>process-test-resources</phase>
 8       <goals>
 9         <goal>time</goal>
10       </goals>
11     </execution>
12   </executions>
13 </plugin>