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() {

            This feature is only for enhancing the development in a local checkout of that project.
            Set the value to an empty string in case you want to disable the feature and always resolve
            the parent POM from the repositories.
          </description>
          <type>String</type>
          <defaultValue>..</defaultValue>
        </field>

// 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 <build><finalName/></build>} rather

     * 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

        }

        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());
    }

      </plugins>
    </pluginManagement>
  </build>
  <modules>
    <module>maven-archiver</module>
    <module>maven-artifact</module>
    <module>maven-artifact-manager</module>
    <module>maven-artifact-ant</module>
    <module>maven-artifact-test</module>
    <module>maven-core</module>
    <module>maven-error-diagnostics</module>
    <module>maven-model</module>
    <module>maven-monitor</module>

     * 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

 *
 * @since 4.0.0
 * @see org.apache.maven.api.services.DependencyResolver
 * @see DependencyScope
 */
@Experimental
@Immutable
public interface PathScope extends ExtensibleEnum {

    // TODO: what if I simply want all dependencies ?
    @Nonnull
    ProjectScope projectScope();

    @Nonnull
    Set<DependencyScope> dependencyScopes();

    PathScope MAIN_COMPILE = pathScope(
            "main-compile",