* This type is created by calls to {@link #patchModule(String)} and a new instance must be created for
 * every module to patch.</p>
 *
 * <p>Path types are often exclusive. For example, a dependency should not be both on the Java class-path
 * and on the Java module-path.</p>
 *
 * @see org.apache.maven.api.services.DependencyResolverResult#getDispatchedPaths()
 *
 * @since 4.0.0
 */
@Experimental

er<? super T>> matchers) Creates a matcher that matches if the examined object matches ALL of the specified matchers. For example: assertThat("myValue", allOf(startsWith("my"), containsString("Val"))) allOf public static <T> Matcher<T> allOf(Matcher<? super T>... matchers) Creates a matcher that matches if the examined object matches ALL of the specified matchers. For example: assertThat("myValue", allOf(startsWith("my"), containsString("Val"))) allOf public static <T> Matcher<T> allOf(Matcher<?...

remainingProjects=example:module-c...

        repository.applyResumptionData(request, rootProject);

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

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

 files for and see if we can't incorporate it all into the POM. Or if we do
 have properties file (something I would like to avoid) say they don't
 contribute in any meaningful way to information in the POM. For example a
 properties file could be used the specify $ so it can be interpolated in
 <developerConnection/> but you couldn't use a properties file to specify the
 version of your project say. Anyway, food for thought to begin with.

    <modelVersion>4.0.0</modelVersion>

    <groupId>org.example</groupId>
    <artifactId>parent</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <packaging>pom</packaging>

    <properties>
        <codehaus.groupId>org.codehaus.mojo</codehaus.groupId>
    </properties>

 *
 * @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.
    }

     2. append happens at plugin level first, then goal level, independently from phases.
        This means for example that adding pluginA:goal2 to pre-existing (pluginA:goal1, pluginB:goal) will lead to (pluginA:goal1, pluginA:goal2, pluginB:goal)