</description>

  <build>
    <plugins>
      <!-- NOTE: It's essential part of this test variant to redefine the test plugin again, i.e. trigger plugin merging -->
      <plugin>
        <groupId>org.apache.maven.its.plugins</groupId>
        <artifactId>maven-it-plugin-log-file</artifactId>
        <version>2.1-SNAPSHOT</version>
      </plugin>
    </plugins>

                for (Plugin element : src) {
                    if (element.isInherited() || !element.getExecutions().isEmpty()) {
                        // NOTE: Enforce recursive merge to trigger merging/inheritance logic for executions
                        Plugin plugin = Plugin.newInstance(false);
                        plugin = mergePlugin(plugin, element, sourceDominant, context);

     * anything useful.
     */
    @Test
    void testMojoThatRequiresExecutionToAGivenPhaseBeforeExecutingItself() throws Exception {}

    // test that mojo which does not require dependency resolution trigger no downloading of dependencies

    // test interpolation of basedir values in mojo configuration

    // test a build where projects use different versions of the same plugin

    @Test

     | to accomplish, particularly when you only have a list of profile id's for debug.
     |
     | This profile example uses the JDK version to trigger activation, and provides a JDK-specific repo.
    <profile>
      <id>jdk-1.4</id>

      <activation>
        <jdk>1.4</jdk>
      </activation>

      <repositories>
        <repository>

/**
 * Extension point that allows build extensions observe and possibly veto mojo executions.
 * <p>
 * Unlike {@link org.apache.maven.execution.MojoExecutionListener}, this extension point does not
 * trigger instantiation of the component, hence "weak" class name prefix. Only applies to mojo execution
 * scoped components.
 * </p>

        </field>
        <field>
          <name>activation</name>
          <version>1.0.0</version>
          <description><![CDATA[The conditional logic which will automatically
            trigger the inclusion of this profile.]]></description>
          <association>
            <type>Activation</type>
          </association>
        </field>
        <field>
          <name>properties</name>

          <version>1.0.0+</version>
          <type>String</type>
          <description>
            Description with the reason of Mojo deprecation. Similar to Javadoc {@code @deprecated}
            This will trigger a warning when a user tries to use a Mojo marked as deprecated.
          </description>
        </field>
        <field>
          <name>configurator</name>
          <version>1.0.0+</version>

      </description>
      <fields>
        <field>
          <name>activation</name>
          <version>1.0.0+</version>
          <description>
            The conditional logic which will automatically trigger the inclusion of this profile.
          </description>
          <association>
            <type>Activation</type>
          </association>
        </field>
        <field>
          <name>properties</name>

 *
 * @since 4.0.0
 */
@Experimental
@FunctionalInterface
@Consumer
public interface Mojo {
    /**
     * Perform whatever build-process behavior this <code>Mojo</code> implements.<br>
     * This is the main trigger for the <code>Mojo</code> inside the <code>Maven</code> system, and allows
     * the <code>Mojo</code> to communicate errors.
     *
     * @throws MojoException if a problem occurs
     */
    void execute();

          </description>
        </field>
        <field>
          <name>activation</name>
          <version>4.0.0+</version>
          <description>The conditional logic which will automatically trigger the inclusion of this
            profile.</description>
          <association>
            <type>Activation</type>
          </association>
        </field>
        <field xml.tagName="build">