* 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);

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>

  <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>

     * (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>

import org.apache.maven.api.model.ReportPlugin;
import org.apache.maven.api.model.Reporting;
import org.apache.maven.model.v4.MavenMerger;

/**
 * As long as Maven controls the BuildPomXMLFilter, the entities that need merging are known.
 * All others can simply be copied from source to target to restore the locationTracker
 *
 * @since 4.0.0
 */
class FileToRawModelMerger extends MavenMerger {

    @Override

        return null;
    }

    public void setRepository(ArtifactRepository remoteRepository) {
        /*
         * NOTE: Metadata at the g:a level contains a collection of available versions. After merging, we can't tell
         * which repository provides which version so the metadata manager must not restrict the artifact resolution to
         * the repository with the most recent updates.
         */
    }