* the first occurrence. So when we're in lenient/compat mode, we have to deal with such broken POMs and mimic
         * the way 2.x works. When we're in strict mode, the removal of duplicates just saves other merging steps from
         * aftereffects and bogus error messages.
         */
        List<Dependency> dependencies = model.getDependencies();
        Map<String, Dependency> normalized = new LinkedHashMap<>(dependencies.size() * 2);

        PomTestWrapper pom = buildPom("plugin-exec-merging-wo-version/sub");
        assertEquals(4, ((List<?>) pom.getValue("build/plugins[1]/executions")).size());
    }

    /* MNG-3943*/
    @Test
    void testMergeOfPluginExecutionsWhenChildAndParentUseDifferentPluginVersions() throws Exception {
        PomTestWrapper pom = buildPom("plugin-exec-merging-version-insensitive/sub");

import org.apache.maven.model.Plugin;
import org.apache.maven.model.PluginContainer;

/** @deprecated */
@Deprecated
public final class ModelUtils {

    /**
     * This should be the resulting ordering of plugins after merging:
     * <p>
     * Given:
     * <pre>
     * parent: X -&gt; A -&gt; B -&gt; D -&gt; E
     * child: Y -&gt; A -&gt; C -&gt; D -&gt; F
     * </pre>
     * Result:
     * <pre>

                        .map(Object::toString)
                        .toList();
                if (!Objects.equals(oldRepos, newRepos)) {
                    logger.debug("Merging repositories from " + model.getId() + "\n"
                            + newRepos.stream().map(s -> "    " + s).collect(Collectors.joining("\n")));
                }
            }

     */
    boolean isProjectBuild();

    /**
     * Specifies whether plugin processing should take place for the built model.
     * This involves merging plugins specified by the {@link org.apache.maven.api.Packaging},
     * configuration expansion (merging configuration defined globally for a given plugin
     * using {@link org.apache.maven.api.model.Plugin#getConfiguration()}

  <artifactId>parent</artifactId>
  <version>0.1</version>
  <packaging>pom</packaging>

  <name>Maven Integration Test :: MNG-3979</name>
  <description>
    Test that during inheritance the merging/joining of subtrees with equal identifier doesn't crash if the parent
    POM has a non-empty element and the child POM has an empty element to join.
  </description>

  <properties>
    <prop0>test</prop0>

          <name>id</name>
          <type>String</type>
          <required>true</required>
          <description>The unique id for this report set, to be used during POM inheritance and profile injection
            for merging of report sets.
          </description>
          <defaultValue>default</defaultValue>
        </field>
        <field>
          <name>reports</name>
          <version>4.0.0+</version>

     * (if applicable). This process will essentially remove duplicate repositories by merging them into one equivalent
     * repository. It is worth to point out that merging does not simply choose one of the input repositories and
     * discards the others but actually combines their possibly different policies.
     *

    <artifactId>parent</artifactId>
    <version>0.1</version>
  </parent>

  <artifactId>child</artifactId>

  <name>Maven Integration Test :: MNG-3979</name>
  <description>
    Test that during inheritance the merging/joining of subtrees with equal identifier doesn't crash if the parent
    POM has a non-empty element and the child POM has an empty element to join.
  </description>

  <properties/>

  <repositories>

  .
  .
  .
</plugins>

We need this form so that the model builder can make the first pass at merging. Full merging cannot be done because we don't know what the version of the plugin is yet that the user has requested. For plugins in the default lifecycle they are typically defined in the plugin management section of the parent POM. When the merging is complete we are going to have something that looks like the following:

<plugins>
  <plugin>