repository.applyResumptionData(request, rootProject);

        assertThat(
                request.getProjectActivation().getOptionalActiveProjectSelectors(),
                containsInAnyOrder("example:module-c"));
    }

 * A {@code PathType} can identify the Java class-path, the Java module-path,
 * or another kind of path for another programming language for example.
 * Path types are often exclusive. For example, a dependency should not be
 * both on the Java class-path and on the Java module-path.
 *
 * @see org.apache.maven.api.services.DependencyResolverResult#getDispatchedPaths()
 *
 * @since 4.0.0

public interface PluginValidationManager {
    enum IssueLocality {
        /**
         * Issue is "user actionable", is internal to the currently built project and is reparable from scope of it
         * by doing some change (for example by changing POM and fixing the problematic plugin configuration).
         */
        INTERNAL,

        /**
         * Issue (present in some plugin) is "developer actionable" (of given plugin, by changing code and doing

            for (PluginExecution execution : plugin.getExecutions()) {
                // if the phase is specified then I don't have to go fetch the plugin yet and pull it down
                // to examine the phase it is associated to.
                if (execution.getPhase() != null) {
                    Map<Integer, List<MojoExecution>> phaseBindings = mappings.get(execution.getPhase());

        }

        return new VersionRange(recommendedVersion, copiedRestrictions);
    }

    /**
     * <p>
     * Create a version range from a string representation
     * </p>
     * Some spec examples are:
     * <ul>
     * <li><code>1.0</code> Version 1.0 as a recommended version</li>
     * <li><code>[1.0]</code> Version 1.0 explicitly only</li>

     * We should always check whether the request pom project is collected.
     * The integration tests for MNG-6223 are examples for this scenario.
     *
     * @return true if the collected projects contain the requested project (for example with -f)
     */
    private boolean isRequestedProjectCollected(MavenExecutionRequest request, List<MavenProject> projects) {

 *
 * @since 4.0.0
 */
@Experimental
@Consumer
public interface VersionRangeResolver extends Service {

    /**
     * Expands a version range to a list of matching versions, in ascending order.
     * For example, resolves "[3.8,4.0)" to "3.8", "3.8.1", "3.8.2".
     * The returned list of versions is only dependent on the configured repositories and their contents.

                    type.getPathTypes().contains(JavaPathType.CLASSES));
            // TODO: watch out for module path
        });

        // Note: here, type decides is artifact added to "build path" (for example during resolution)
        // and "build path" is intermediate data that is used to create actual Java classpath/modulepath
        // but to create those, proper filtering should happen via Type properties.
    }

    @Nonnull
    PathScope getPathScope();

    /**
     * Returns a filter for the types of path (class-path, module-path, …) accepted by the tool.
     * For example, if a Java tools accepts only class-path elements, then the filter should return
     * {@code true} for {@link JavaPathType#CLASSES} and {@code false} for {@link JavaPathType#MODULES}.

     */
    @Nonnull
    List<Path> getPaths();

    /**
     * Returns the file paths of all dependencies, dispatched according the tool options where to place them.
     * The {@link PathType} keys identify, for example, {@code --class-path} or {@code --module-path} options.
     * In the case of Java tools, the map may also contain {@code --patch-module} options, which are