Maven 默认生命周期和插件部分
Maven default life-cycle and plugins section
如有错误请指正。如果 Maven pom.xml 中没有定义包装类型，则默认使用 jar 生命周期。
每个 Maven 打包类型都有一个默认的构建生命周期和相关的默认目标。 （我们可以将 goal 视为 plugin + command）
生命周期阶段目标
- 进程资源resources:resources
- 编译compiler:compile
- 进程测试资源resources:testResources
- 测试编译compiler:testCompile
- 测试surefire:test
- 套餐jar:jar
- 安装install:install
- 部署deploy:deploy
我的问题是:
在定义打包类型时，我们是否可以说 pom.xml 插件部分填充了该打包构建生命周期的默认插件和目标？
另外：
如果我们在插件部分定义一个插件，比如编译器插件，并给出它的配置，这些配置是否覆盖插件默认配置？
If not packing type is defined in a maven pom.xml, jar lifecyle is used.
几乎正确，jar不是生命周期，是包装。 Maven 有 three build life cycles (clean, default, site) 可以应用于任何包装。
根据官方Maven model
packaging The type of artifact this project produces, for example jar war ear pom. Plugins can create their own packaging, and therefore their own packaging types, so this list does not contain all possible types.
Default value is: jar.
Every maven packaging type has a default build lifecycle
它没有默认的生命周期，你在它的项目上调用默认的生命周期。它具有默认生命周期 default bindings，也就是说，插件已经根据定义的 packaging 类型默认附加到默认生命周期的阶段。
Maven 的core concepts 之一是约定优于配置。它的默认绑定强制执行这一原则，已经为给定的包装提供了某些插件的某些目标的执行。
例如，默认情况下已经需要编译（通过 maven-compiler-plugin 及其在 compile 阶段的 compile 目标）、测试（通过 maven-surefire-plugin 及其 test 目标在 test 阶段）和打包（通过 maven-jar-plugin 及其在 package 阶段的 jar 目标）你的项目在应用默认值时（jar) 包装。
（注意模式：我提到了一个插件，一个目标，一个阶段，也就是默认绑定）。
这就是 minimal pom 已经可以做很多事情的原因：同样，它是约定优于配置。
While defining a packaging type can we say that is as if the pom.xml plugins section gets populated with the default plugins and goals for that packaging build lifecycle?
事实上，这就像使用默认配置填充构建 plugins 部分，执行默认附加插件和目标并分配给某些阶段。
还要注意，如果您添加相同插件和目标的进一步执行，它将在默认绑定指定的那个之上（之后）被调用。请参阅下文如何在需要时防止它。
If we define a plugin in the plugin section, say for example compiler plugin,
and give it configurations, do these configuration override the plugin default configurations?
您可以定义更多插件和 executions 它们的一个或多个目标，附加到特定阶段。每个 execution 可以有一个自定义 configuration。但是，不在任何 execution 部分内但声明为 generic/global 配置的 configuration 将应用于相关插件的 任何执行 和同样也适用于通过打包绑定默认附加的那些。
来自官方 POM reference 关于 configuration 元素
The default behavior is to merge the content of the configuration element according to element name. If the child POM has a particular element, that value becomes the effective value. if the child POM does not have an element, but the parent does, the parent value becomes the effective value.
关于 execution 部分的 configuration 元素：
configuration: Same as above, but confines the configuration to this specific list of goals, rather than all goals under the plugin.
这就是为什么您经常看到 maven-compiler-plugin 的 source/target 配置不同，而没有任何 execution。它将应用于已通过默认绑定附加的 compile（源代码编译）和 testCompile（测试代码编译）目标的默认执行。
此外，您甚至可以通过为相同插件、相同目标、相同执行 ID 添加 execution 来覆盖默认绑定并将其从特定阶段删除（最重要的一点）并将其附加到不同的阶段或不存在的阶段（或空）阶段。因此，您将禁用默认插件目标执行。您还可以使用此技巧将您的插件目标执行添加为同一阶段的首次执行：通过禁用默认执行，添加您的执行，然后重新定义默认执行（然后使用不同的 id）。然后 Maven 将遵循执行声明顺序。
勾选 on how execution ids are generated. The important point here would be, from official Maven documentation
each mojo bound to the build lifecycle via the default lifecycle mapping for the specified POM packaging will have an execution Id of default-goalName assigned to it
如有错误请指正。如果 Maven pom.xml 中没有定义包装类型，则默认使用 jar 生命周期。
每个 Maven 打包类型都有一个默认的构建生命周期和相关的默认目标。 （我们可以将 goal 视为 plugin + command）
生命周期阶段目标
- 进程资源resources:resources
- 编译compiler:compile
- 进程测试资源resources:testResources
- 测试编译compiler:testCompile
- 测试surefire:test
- 套餐jar:jar
- 安装install:install
- 部署deploy:deploy
我的问题是:
在定义打包类型时，我们是否可以说 pom.xml 插件部分填充了该打包构建生命周期的默认插件和目标？
另外：
如果我们在插件部分定义一个插件，比如编译器插件，并给出它的配置，这些配置是否覆盖插件默认配置？
If not packing type is defined in a maven pom.xml, jar lifecyle is used.
几乎正确，jar不是生命周期，是包装。 Maven 有 three build life cycles (clean, default, site) 可以应用于任何包装。
根据官方Maven model
packagingThe type of artifact this project produces, for example jar war ear pom. Plugins can create their own packaging, and therefore their own packaging types, so this list does not contain all possible types.
Default value is:jar.
Every maven packaging type has a default build lifecycle
它没有默认的生命周期，你在它的项目上调用默认的生命周期。它具有默认生命周期 default bindings，也就是说，插件已经根据定义的 packaging 类型默认附加到默认生命周期的阶段。
Maven 的core concepts 之一是约定优于配置。它的默认绑定强制执行这一原则，已经为给定的包装提供了某些插件的某些目标的执行。
例如，默认情况下已经需要编译（通过 maven-compiler-plugin 及其在 compile 阶段的 compile 目标）、测试（通过 maven-surefire-plugin 及其 test 目标在 test 阶段）和打包（通过 maven-jar-plugin 及其在 package 阶段的 jar 目标）你的项目在应用默认值时（jar) 包装。
（注意模式：我提到了一个插件，一个目标，一个阶段，也就是默认绑定）。
这就是 minimal pom 已经可以做很多事情的原因：同样，它是约定优于配置。
While defining a packaging type can we say that is as if the pom.xml plugins section gets populated with the default plugins and goals for that packaging build lifecycle?
事实上，这就像使用默认配置填充构建 plugins 部分，执行默认附加插件和目标并分配给某些阶段。
还要注意，如果您添加相同插件和目标的进一步执行，它将在默认绑定指定的那个之上（之后）被调用。请参阅下文如何在需要时防止它。
If we define a plugin in the plugin section, say for example compiler plugin, and give it configurations, do these configuration override the plugin default configurations?
您可以定义更多插件和 executions 它们的一个或多个目标，附加到特定阶段。每个 execution 可以有一个自定义 configuration。但是，不在任何 execution 部分内但声明为 generic/global 配置的 configuration 将应用于相关插件的 任何执行 和同样也适用于通过打包绑定默认附加的那些。
来自官方 POM reference 关于 configuration 元素
The default behavior is to merge the content of the
configurationelement according to element name. If the child POM has a particular element, that value becomes the effective value. if the child POM does not have an element, but the parent does, the parent value becomes the effective value.
关于 execution 部分的 configuration 元素：
configuration: Same as above, but confines the configuration to this specific list of goals, rather than all goals under the plugin.
这就是为什么您经常看到 maven-compiler-plugin 的 source/target 配置不同，而没有任何 execution。它将应用于已通过默认绑定附加的 compile（源代码编译）和 testCompile（测试代码编译）目标的默认执行。
此外，您甚至可以通过为相同插件、相同目标、相同执行 ID 添加 execution 来覆盖默认绑定并将其从特定阶段删除（最重要的一点）并将其附加到不同的阶段或不存在的阶段（或空）阶段。因此，您将禁用默认插件目标执行。您还可以使用此技巧将您的插件目标执行添加为同一阶段的首次执行：通过禁用默认执行，添加您的执行，然后重新定义默认执行（然后使用不同的 id）。然后 Maven 将遵循执行声明顺序。
勾选
each mojo bound to the build lifecycle via the default lifecycle mapping for the specified POM packaging will have an execution Id of
default-goalNameassigned to it