this.session = session;
        this.mojoExecution = mojoExecution;
        this.properties = new Properties();
        this.project = session.getCurrentProject();

        //
        // Maven4: We may want to evaluate how this is used but we add these separate as the
        // getExecutionProperties is deprecated in MavenSession.
        //
        this.properties.putAll(session.getUserProperties());

        return getPhaseToLifecycleMap().get(phase);
    }

    /**
     * We use this to map all phases to the lifecycle that contains it. This is used so that a user can specify the
     * phase they want to execute and we can easily determine what lifecycle we need to run.
     *
     * @return A map of lifecycles, indexed on id
     */
    public Map<String, Lifecycle> getPhaseToLifecycleMap() {

        } catch (IOException e) {
            throw new UncheckedIOException(e);
        }
    }

    /**
     * Returns {@code true} if passed in artifact is originating from local repository. In other words, we want
     * to process and store tracking information ONLY into local repository, not to any other place. This method
     * filters out currently built artifacts, as events are fired for them as well, but their resolved artifact

            url = "file://" + url.substring("file:".length());
        }

        // So now we have an url of the form file://<path>

        // We want to eliminate any relative path nonsense and lock down the path so we
        // need to fully resolve it before any submodules use the path. This can happen

// It would be cool if there was a hook that I could use to set up a test environment.
// I want to set up a local/remote repositories for testing but I don't want to have
// to change them when I change the layout of the repositories. So I want to generate
// the structure I want to test by using the artifact handler manager which dictates
// the layout used for a particular artifact type.

/**
 */

     * configuration). This is useful when you want to force the user to use common POM elements rather than plugin
     * configurations, as in the case where you want to use the artifact's final name as a parameter. In this case, you
     * want the user to modify <code>&lt;build&gt;&lt;finalName/&gt;&lt;/build&gt;</code> rather than specifying a value

     * on the command line.
     */
    private List<MavenProject> projects;

    /**
     * The full set of projects before any potential constraining by --projects. Useful in the case where you want to
     * build a smaller set of projects but perform other operations in the context of your reactor.
     */
    private List<MavenProject> allProjects;

    private MavenProject topLevelProject;

                new ManagedDependencyContextRefiner(getScopeManager()));
    }

    /**
     * This method produces "surrogate" type registry that is static: it aims users that want to use
     * Maven-Resolver without involving Maven Core and related things.
     * <p>
     * This type registry is NOT used by Maven Core: Maven replaces it during Session creation with a type registry

import org.apache.maven.artifact.repository.ArtifactRepository;
import org.apache.maven.artifact.versioning.OverConstrainedVersionException;

/**
 * Specific problems during resolution that we want to account for:
 * <ul>
 *   <li>missing metadata</li>
 *   <li>version range violations</li>
 *   <li>version circular dependencies</li>
 *   <li>missing artifacts</li>
 *   <li>network/transfer errors</li>

        }

        return request;
    }

    // layer the creation of a project builder configuration with a request, but this will need to be
    // a Maven subclass because we don't want to couple maven to the project builder which we need to
    // separate.
    protected MavenSession createMavenSession(File pom) throws Exception {
        return createMavenSession(pom, new Properties());
    }