了解Maven插件管理部分

Question

我了解 pluginManagement 部分通常位于父级

pom.xml

中，用于定义跨项目的通用配置。如果子模块想要像 OOP 中的经典继承一样，则可以选择覆盖它。

但是如果我们以 this

pom.xml

为例，它不包含任何

pluginManagement

部分，而是在

plugins

下定义

build -> plugins

。

问题：以下之间有什么区别：

<build>
        <plugins>
            <plugin>

和

<build>
  <pluginManagement>
        <plugins>
            <plugin>

在this页面上我找到了以下文档：

如果您的 POM 声明了父级，它将从父级的 build/plugins 或 pluginManagement 部分继承插件配置。

问题：

1. 如果我在父级

   pom.xml

   中定义了构建/插件和pluginManagement，并且两者之间存在不一致，会发生什么？例如，在 build/plugins 中，我定义了版本 X 的插件 foo，在 pluginManagement 中，我定义了版本 Y 的插件 foo，并进一步使用了不同的配置？
2. 意图（最佳实践）是使用构建/插件或插件管理之一，而不是同时使用两者？
3. 添加两种方法来实现同一件事能达到什么目的？

Answer 1

我不确定是否值得潜入那个兔子洞......让我们尝试一下......

当我们谈论 Maven 插件配置时，我们实际上对以下内容感兴趣：

• 将调用哪些插件目标
• 这些目标的实际配置是什么

这些问题的最佳且唯一的答案如下：

您需要运行

mvn help:effective-pom

并分析结果

但是，我确实相信这不是您所期望的答案。

Maven 使用以下策略来合并插件配置：

• 父

  plugins

  元素合并到子

  plugins

  元素
• 父

  pluginManagement

  元素合并到子

  pluginManagement

  元素
• 生成的子

  pluginManagement.plugins

  元素合并到子

  plugins

  元素
• 生成的子

  plugins

  元素被扩展，即生成的

  plugin.configuration

  元素被合并到生成的

  plugin.executions.execution.configuration

  元素

基于上面描述的策略，我想说

pluginManagement

部分的使用绝对是多余的，而且，它使很多事情变得复杂，下面是一些支持不使用

pluginManagement

的其他论点：

• IDE（在这里我只能代表

  IntellyJ

  ）不将

  pluginManagement

  部分识别为您可以在构建生命周期之外执行的插件源，例如如果我的目标是定期执行dependency-check:aggregate，我需要在build.plugins

  中定义它（否则

  IntellyJ

  无法识别它）或通过

  terminal

  窗口执行，这是非常不方便的（

  IntellyJ

  ）也不支持执行标识符，但这是另一个故事）。

大多数现代 Maven 插件确实支持
• <skip>

   配置元素，因此我们可以通过 

  properties

   部分控制特定 Maven 插件的执行，而不是编写那些冗长的 XML，此外，这证明了通过配置插件的整体想法

  pluginManagement

  然后在

  build.plugins

  中定义插件是错误的