assertEquals(1, depResults.size());
        assertEquals(
                exec.getPlugin().getArtifact().key(),
                depResults.iterator().next().key(),
                "dependency artifact is wrong.");
    }

    @Test
    public void testPluginArtifactMapExpressionReference() throws Exception {
        Session session = newSession();

        MojoExecution exec = newMojoExecution(session);

        System.out.println("Result: " + depResults);

        assertNotNull(depResults);
        assertEquals(1, depResults.size());
        assertSame(depArtifact, depResults.get(0), "dependency artifact is wrong.");
    }

    @Test
    void testPluginArtifactMapExpressionReference() throws Exception {
        MojoExecution exec = newMojoExecution();

                // because it wasn't deployed, or it was deployed in the wrong place.

                synchronized (result) {
                    result.addMissingArtifact(artifact);
                }
            } catch (ArtifactResolutionException e) {
                // This is really a wagon TransferFailedException so something went wrong after we successfully
                // retrieved the metadata.

    <<online>> status, or else doesn't care.

  * Otherwise, don't bind the mojo. Log a debug message to indicate that it is
    sensitive the online state of the application, and that this state is
    currently wrong for execution.

    <<NOTE:>> Do we want to fail when we cannot bind a mojo to the lifecycle
    because of offline/online status? That would probably indicate that the user

                        .resumeFrom(MODULE_B)
                        .inactiveRequiredProjects(MODULE_B)
                        .expectResult(MODULE_C_2, INDEPENDENT_MODULE),
                scenario("Selected projects in wrong order are resumed correctly in order")
                        .activeRequiredProjects(MODULE_C_2, MODULE_B, MODULE_A)
                        .resumeFrom(MODULE_B)
                        .expectResult(MODULE_B, MODULE_C_2),

- plugin dependency metadata retrieval problem
- plugin configuration problem
- plugin execution failure due to something that is know to possibly go wrong (like compilation failure)
- plugin execution error due to something that is not expected to go wrong (the compiler executable missing)
- asking to use a plugin for which you do not have a version defined - tools to easily select versions

            /*
             * This logic (using filesystem, against wanted independence from the user environment) exists only for the
             * sake of backward-compat with 2.x (MNG-5000). In general, it is wrong to
             * base URL inheritance on the module directory names as this information is unavailable for POMs in the
             * repository. In other words, modules where artifactId != moduleDirName will see different effective URLs