Java Maven默认生命周期和插件部分

如果我错了，请纠正我。如果Maven

pom.xml

中未定义打包类型，则默认情况下使用

jar

lifecycle

每个Maven打包类型都有一个默认的构建生命周期和相关的默认目标。（我们可以将目标视为插件+命令）

生命周期阶段目标

• 流程资源：资源
• 编译编译器：编译
• 流程测试资源：testResources
• 测试编译编译器：测试编译
• 测试：测试
• 包jar:jar
• 安装：安装
• 部署：部署

我的问题是：
在定义打包类型时，我们是否可以说，它就好像

pom.xml

plugins部分填充了该打包构建生命周期的默认插件和目标

另外：
如果我们在plugin部分定义一个插件，比如compiler plugin，并给出它的配置，那么这些配置会覆盖插件的默认配置吗

如果maven pom.xml中没有定义打包类型，则使用jar生命周期

几乎正确，

jar

不是一个生命周期，而是一个包装。Maven有三个可应用于任何包装的（干净、默认、站点）

按照官方的说法

packaging

此项目产生的工件类型，例如jar war ear pom。插件可以创建自己的包，因此也可以创建自己的包类型，因此此列表不包含所有可能的类型。
默认值为：

jar

---

每个maven打包类型都有一个默认的构建生命周期

它没有默认的生命周期，您可以对其项目调用默认的生命周期。对于默认的生命周期，它有一个定义，也就是说，插件已经根据定义的

包装
类型默认地连接到默认生命周期的各个阶段

Maven的一个特点是约定优于配置。它的默认绑定执行这一原则，已经为给定的打包提供了特定插件的特定目标的执行。

例如，默认情况下，它已经需要编译（在
compile
阶段通过
maven编译器插件及其
compile
目标）、测试（在
test
阶段通过
maven-surefire插件及其
test
目标）和包（在
package
阶段，通过
maven-jar插件及其
jar
目标）在应用默认（
jar
）打包时启动项目。

（注意模式：我提到了一个插件、一个目标、一个阶段，即默认绑定）

这就是为什么服务器可以做很多事情的原因：再一次，它是约定而不是配置


在定义打包类型时，我们是否可以说pom.xml plugins部分填充了该打包构建生命周期的默认插件和目标

事实上，这就像用默认附加插件和目标的执行填充构建
插件
部分，并使用它们的默认配置分配给某些阶段。

另外请注意，如果您添加了相同插件和目标的进一步执行，它将在默认绑定指定的插件和目标之上（之后）被调用。请参阅下面的如何在需要时防止它


如果我们在插件部分定义插件，比如说编译器插件，
给它配置，这些配置会覆盖插件的默认配置吗

您可以定义附加到特定阶段的一个或多个目标的进一步插件和执行。每个执行可以有一个自定义的配置。但是，不在任何执行节中但声明为通用/全局配置的配置将被激活适用于相关插件的任何执行，因此也适用于通过打包绑定默认连接的插件

在
配置
元素上从官方

默认行为是根据元素名称合并
配置
元素的内容。如果子POM具有特定元素，则该值成为有效值。如果子POM没有元素，但父POM有，则父POM值成为有效值

关于
执行
部分的
配置
元素：

配置
：与上面相同，但将配置限制在此特定目标列表中，而不是插件下的所有目标

这就是为什么您经常看到
maven编译器插件
的不同
源
/
目标
配置，没有任何
执行
。它将应用于
编译
（源代码编译）和
测试编译
（测试代码编译）的默认执行已通过默认绑定附加的目标

此外，您甚至可以通过为同一插件、同一目标、同一执行id（最重要的一点）添加
执行
，并将其附加到不同的阶段或不存在的阶段（或空），来覆盖默认绑定并将其从某个阶段移除阶段。同样，您将禁用默认插件目标执行。您可以使用此技巧将插件目标执行添加为同一阶段的第一次执行：通过禁用默认执行，添加执行，然后重新定义默认执行（然后使用不同的id）.Maven随后将遵循执行声明顺序

检查执行ID是如何生成的<