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

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

    @Override
    String id();

    /**
     * Collection of phases for this lifecycle
     */
    Collection<Phase> phases();

    /**
     * Pre-ordered list of phases.
     * If not provided, a default order will be computed.
     */
    default Optional<List<String>> orderedPhases() {
        return Optional.empty();
    }

    /**
     * A phase in the lifecycle.
     */
    interface Phase {

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

  <packaging>JAR</packaging>

  <name>Maven Integration Test :: MNG-4341</name>
  <description>
    Test that plugins bound to the same phase get executed in POM order even if one of the plugins participates
    in the default lifecycle bindings for the project's packaging.
  </description>

  <build>
    <plugins>
      <plugin>

        Predicate<Artifact> predArtifactId = a -> artifactId.matches(createPathProxy(a.getArtifactId()));
        return predGroupId.and(predArtifactId);
    }

    /**
     * In order to reuse the glob matcher from the filesystem, we need
     * to create Path instances.  Those are only used with the toString method.
     * This hack works because the only system-dependent thing is the path

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