* lifecycle phase. Standard lifecycles use plugin execution {@code <phase>} or mojo default lifecycle phase to
 * calculate the execution plan, but custom lifecycles can use alternative mapping strategies.
 */
@Named(DefaultLifecycleMappingDelegate.HINT)
@Singleton
public class DefaultLifecycleMappingDelegate implements LifecycleMappingDelegate {
    public static final String HINT = "default";

import java.util.List;

import org.apache.maven.execution.MavenExecutionRequest;
import org.apache.maven.project.MavenProject;
import org.apache.maven.project.ProjectBuildingException;

/**
 * Describes strategies for finding projects that Maven could build.
 */
public interface ProjectCollectionStrategy {
    /**
     *
     * @param request
     * @return
     * @throws ProjectBuildingException
     */

        VersionRange range2 = VersionRange.createFromVersionSpec("1.1");
        VersionRange mergedRange = range1.restrict(range2);
        // TODO current policy is to retain the original version - is this correct, do we need strategies or is that
        // handled elsewhere?
        //        assertEquals( "1.1", mergedRange.getRecommendedVersion().toString(), CHECK_VERSION_RECOMMENDATION );

    private final ProjectsSelector projectsSelector = new DefaultProjectsSelector(projectBuilder);

    // Not using mocks for these strategies - a mock would just copy the actual implementation.

    private final ModelLocator modelLocator = new DefaultModelLocator();

 * lifecycle phase. Standard lifecycles use plugin execution {@code <phase>} or mojo default lifecycle phase to
 * calculate the execution plan, but custom lifecycles can use alternative mapping strategies.
 * <p>
 * Implementations of this interface must be annotated with either {@code @Named("lifecycle-id")} or equivalent plexus
 * {@code @Component} annotations.
 *
 * @since 3.2.0

- we need to deal with a shared context for plugins, like the guarded mojos
- we need to deal with plugins as core application logic which can also interact with plugins

* Along with this comes the testing strategies that make this work
* The repository model where plugins can be stored and cataloged
* Bridging this into an OSGi system: if this could be done then we can basically take over p2

TODO