<groupId>org.apache.maven.its.mng4193</groupId>
  <artifactId>test</artifactId>
  <version>0.1</version>
  <packaging>jar</packaging>

  <name>Maven Integration Test :: MNG-4193</name>
  <description>
    Test that multiple artifact repository declarations with the same id cause a validation error even if the
    repositories are defined within a (non-active) profile.
  </description>

  <profiles>
    <profile>

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

  <artifactId>child</artifactId>

  <name>Maven Integration Test :: MNG-3938</name>
  <description>
    Test that plugin executions with the same id are merged during inheritance, especially executions using the
    default id, regardless whether the id is given explicitly by the user or implicitly assumed from defaults.

  <groupId>org.apache.maven.its.mng3925</groupId>
  <artifactId>parent</artifactId>
  <version>0.1</version>
  <packaging>pom</packaging>

  <name>Maven Integration Test :: MNG-3925</name>
  <description>
    Test that plugin executions (in the same phase) are properly ordered after inheritance/merge with
    parent executions.
  </description>

  <build>

<project>
  <modelVersion>4.0.0</modelVersion>

  <groupId>org.apache.maven.its.mng3821</groupId>
  <artifactId>test</artifactId>
  <version>1.0-SNAPSHOT</version>

  <name>Maven Integration Test :: MNG-3821</name>
  <description>
    Verify that using the same id for executions/reportsets of different plugins doesn't blow up the project builder.
  </description>

  <build>
    <plugins>
      <plugin>

         * processes one artifact at a time and hence cannot associate the artifacts from the same project to use the
         * same version index. Allowing the caller to pass in metadata from a previous deployment allows to re-establish
         * the association between the artifacts of the same project.
         */
        for (Iterator<? extends Metadata> it = metadatas.iterator(); it.hasNext(); ) {

public class MavenExecutionPlan implements Iterable<ExecutionPlanItem> {

    /*
      At the moment, this class is totally immutable, and this is in line with thoughts about the
      pre-calculated execution plan that stays the same during the execution.

      If deciding to add mutable state to this class, it should be at least considered to
      separate this into a separate mutable structure.

    */

 * <p>
 * Unlike a cache, this session data is not subject to purging. For this same reason, session data should also not be
 * abused as a cache (i.e. for storing values that can be re-calculated) to avoid memory exhaustion.
 * <p>
 * <strong>Note:</strong> Actual implementations must be thread-safe.
 *
 * @see Session#getData()
 * @since 4.0.0
 */
@Experimental
@ThreadSafe
@Provider

 * <tr><td><code>project.*</code></td>         <td></td>               <td></td></tr>
 * <tr><td><code>pom.*</code></td>             <td>(since Maven 3)</td><td>same as <code>project.*</code></td></tr>
 * <tr><td><code>executedProject</code></td>   <td></td>
 *                                             <td>{@link MavenProject#getExecutionProject()}</td></tr>

main channel of communication for contributors.  
There are some guidelines which will make applying PRs easier for us:
+ Create a topic branch from where you want to base your work (this is usually the master branch).
  Push your changes to a topic branch in your fork of the repository.
+ Make commits of logical units.
+ Respect the original code style: by using the same [codestyle][code-style],

  <modelVersion>4.0.0</modelVersion>

  <groupId>org.apache.maven.its.mng3838</groupId>
  <artifactId>test</artifactId>
  <version>1.0-SNAPSHOT</version>

  <name>Maven Integration Test :: MNG-3838</name>
  <description>
    Verify that using the same dependency for different plugins doesn't blow up the project builder.
  </description>

  <build>
    <plugins>
      <plugin>