~~ under the License.

 -----
 Inheritance in Maven
 -----
 The Maven Team
 -----

Inheritance in Maven

 In order the understand how inheritance works in Maven there are a few notions that you must be familiar with:

 * The maven super model

 * how parent poms are processed

 * the order in which elements in the POM are overridden

 * minimum element-set for a valid project pom


Maven super model

public class DefaultProjectDependencyGraph implements ProjectDependencyGraph {

    private final ProjectSorter sorter;

    private final List<MavenProject> allProjects;

    private final Map<MavenProject, Integer> order;

    private final Map<String, MavenProject> projects;

    /**
     * Creates a new project dependency graph based on the specified projects.
     *

          <version>2.1-SNAPSHOT</version>
          <inherited>true</inherited>
          <configuration>
            <listParam>
              <!-- NOTE: These values are deliberately not in alpha order! -->
              <listParam>PARENT-1</listParam>
              <listParam>PARENT-3</listParam>
              <listParam>PARENT-2</listParam>
              <listParam>PARENT-4</listParam>
            </listParam>

                        "site")),
                pom.getValue("reporting/outputDirectory"));
    }

    @Test
    void testPluginOrder() throws Exception {
        PomTestWrapper pom = buildPom("plugin-order");
        assertEquals("plexus-component-metadata", pom.getValue("build/plugins[1]/artifactId"));
        assertEquals("maven-surefire-plugin", pom.getValue("build/plugins[2]/artifactId"));
    }

    @Test

import org.eclipse.aether.resolution.ArtifactDescriptorResult;

/**
 * Maven relocation source.
 * Note: implementations of this component should avoid the "default" name (has special meaning in Eclipse Sisu) and
 * explicitly order implementations using Sisu priorities.
 *
 * @since 4.0.0
 */
public interface MavenArtifactRelocationSource {
    /**
     * Returns {@link Artifact} instance where to relocate to, or {@code null}.
     *

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

  <name>Maven Integration Test :: MNG-3886</name>
  <description>
    Test that the goals from a plugin execution are executed in the order given by the POM, regardless whether
    plugin management is present or not.
  </description>

  <build>
    <!-- This project uses plugin management for the test plugin -->
    <pluginManagement>
      <plugins>

  <name>Maven Integration Test :: MNG-4107</name>
  <description>
    Test that POM interpolation uses the property values from the dominant profile source (POM vs. settings.xml).
    This boils down to the proper order of profile injection and interpolation, i.e.
    interpolate after profiles from all sources are injected.
  </description>

  <properties>
    <!-- collect the effective property values as derived by interpolation -->

     *
     * @return the severity level of this problem, never {@code null}
     */
    @Nonnull
    Severity getSeverity();

    /**
     * The different severity levels for a problem, in decreasing order.
     *
     * @since 4.0.0
     */
    @Experimental
    enum Severity {
        FATAL, //
        ERROR, //
        WARNING //
    }

         * NOTE: This is primarily to keep backward-compat with Maven 2.x which did not validate that dependencies are
         * unique within a single POM. Upon multiple declarations, 2.x just kept the last one but retained the order of
         * the first occurrence. So when we're in lenient/compat mode, we have to deal with such broken POMs and mimic

// TODO lifecycles being executed
// TODO what runs in each phase
// TODO plugins that need downloading
// TODO project dependencies that need downloading
// TODO unfortunately the plugins need to be downloaded in order to get the plugin.xml file. need to externalize this
//      from the plugin archive.
// TODO this will be the class that people get in IDEs to modify

/**
 * MavenExecutionPlan
 */