under the License.
-->

<project>
  <modelVersion>4.0.0</modelVersion>
  <artifactId>aid</artifactId>
  <groupId>gid</groupId>
  <version>0.1</version>
  <packaging>pom</packaging>

  <profiles>
    <profile>
      <id>non-unique-id</id>
    </profile>
    <profile>
      <id>non-unique-id</id>
    </profile>
  </profiles>

- circular dependency
- artifact missing
- artifact retrieval exception
- md5 checksum doesn't match for local artifact, need to redownload this
- POM doesn't exist for a goal that requires one
- parent POM missing (in both the repository + relative path)
- component not found

Plugins:
- plugin metadata missing
- plugin metadata retrieval problem
- plugin artifact missing
- plugin artifact retrieval problem

  In order to really achieve this, we need mojo configurations (which are
  provided both in terms of static expressions that are just looked up, and
  in terms of user-provided configuration from properties or the POM).
  If these mojos are to be first-class components, the configuration from these
  various sources must be consolidated and injected using the container.

  Currently, mojo configuration is done externally to the container, in the

  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>test</groupId>
        <artifactId>a</artifactId>
        <version>0.1</version>
        <scope>import</scope>
        <!-- missing type=pom -->
      </dependency>
    </dependencies>
  </dependencyManagement>

    // <plugin/> block in a Maven POM. We have to do some wiggling to pull the sources of information
    // together and this really shows the problem of constructing a sensible default configuration, but
    // it's all encapsulated here so it appears normalized to the POM builder.

    // We are going to take the project packaging and find all plugin in the default lifecycle and create

        // Distinct the projects to avoid duplicates.  Duplicates are possible in multi-module projects.
        //
        // Given a scenario where there is an aggregate POM with modules A, B, C, D, and E and project E depends on
        // A, B, C, and D. If the aggregate POM is being filtered for non-transitive and downstream dependencies where
        // only A, C, and E are whitelisted duplicates will occur. When scanning projects A, C, and E, those will be

    void testPom() throws Exception {
        ArtifactRepository remoteRepository = remoteRepository();

        ArtifactRepository localRepository = localRepository();

        Artifact a = createArtifact("a", "0.0.1", "pom");
        File file = new File(localRepository.getBasedir(), localRepository.pathOf(a));
        file.delete();
        a.setFile(file);

        File touchFile = updateCheckManager.getTouchfile(a);

    }

    /**
     * Gets the identifier of the POM whose effective model could not be built. The general format of the identifier is
     * {@code <groupId>:<artifactId>:<version>} but some of these coordinates may still be unknown at the point the
     * exception is thrown so this information is merely meant to assist the user.
     *
     * @return The identifier of the POM or an empty string if not known, never {@code null}.
     */

                .getMavenSession()
                .getRequest()
                .setRootDirectory(Paths.get("src/test/resources/consumer/trivial"));

        Path file = Paths.get("src/test/resources/consumer/trivial/child/pom.xml");

        ModelBuilder.ModelBuilderSession mbs = modelBuilder.newSession();
        InternalSession.from(session).getData().set(SessionData.key(ModelBuilder.ModelBuilderSession.class), mbs);

under the License.
-->

<project>
  <modelVersion>4.0.0</modelVersion>
  <artifactId>aid</artifactId>
  <groupId>gid</groupId>
  <version>0.1</version>
  <packaging>pom</packaging>

  <modules>
    <module>child</module>
    <module>child</module>
  </modules>