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

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

        // snapshot timestamp, or some other timestamp later encoded into the metadata.
        // TODO this needs to be repeated here so the merging doesn't interfere with the written metadata
        //  - we'd be much better having a pristine input, and an ongoing metadata for merging instead

        Map<ArtifactRepository, Metadata> previousMetadata = new HashMap<>();
        ArtifactRepository selected = null;

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

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>

        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.
         */
    }

   * and column pair, they will be combined with the specified merging function in encounter order.
   *
   * <p>The returned {@code Collector} will throw a {@code NullPointerException} at collection time
   * if the row, column, value, or merging functions return null on any input.
   *
   * @since 33.2.0 (available since 21.0 in guava-jre)
   */

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

 {{{http://www.slf4j.org/manual.html#swapping}"SLF4J bindings"}}.

 Logging configuration loading is actually done by logging implementation, without any Maven extensions to support merging
 Maven installation configuration with per-user configuration for example:
 <<<$\{maven.conf}/logging>>> directory was added to core's classpath (see <<<$\{maven.home}/bin/m2.conf>>>). See your implementation

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
 * @deprecated use {@link org.apache.maven.api.services.ModelBuilder} instead
 */