* base URL inheritance on the module directory names as this information is unavailable for POMs in the
             * repository. In other words, modules where artifactId != moduleDirName will see different effective URLs
             * depending on how the model was constructed (from filesystem or from repository).
             */

                // This means a module which is build has a dependency which has the same
                // groupId, artifactId, version and classifier coordinates. This is in consequence
                // a self reference or in other words a circular reference which can not being resolved.
                addViolation(
                        problems,
                        Severity.FATAL,
                        Version.V31,

         * the first occurrence. So when we're in lenient/compat mode, we have to deal with such broken POMs and mimic
         * the way 2.x works. When we're in strict mode, the removal of duplicates just saves other merging steps from
         * aftereffects and bogus error messages.
         */
        List<Dependency> dependencies = model.getDependencies();

     * @return true if the OS matches
     *
     */
    public static boolean isFamily(String family, String actualOsName) {
        // windows probing logic relies on the word 'windows' in the OS
        boolean isWindows = actualOsName.contains(FAMILY_WINDOWS);
        boolean is9x = false;
        boolean isNT = false;
        if (isWindows) {

    @BeforeEach
    void setUp() throws Exception {
        source = new Source();

        projectArtifact = createArtifactSpec("project", "1.0", null);
    }

    @Test
    @Disabled("works, but we don't fail on cycles presently")
    void testCircularDependencyNotIncludingCurrentProject()
            throws ArtifactResolutionException, InvalidVersionSpecificationException {

import org.apache.maven.api.services.model.ModelVersionParser;

import static org.apache.maven.internal.impl.Utils.nonNull;

/**
 * A wrapper class around a resolver version that works as model version parser as well.
 */
@Named
@Singleton
public class DefaultVersionParser implements VersionParser {
    private final ModelVersionParser modelVersionParser;

    @Inject

import org.eclipse.aether.repository.RemoteRepository;
import org.slf4j.LoggerFactory;

// TODO the antrun plugin has its own configurator, the only plugin that does. might need to think about how that works
// TODO remove the coreArtifactFilterManager

/**
 * DefaultBuildPluginManager
 */
@Named
@Singleton
public class DefaultBuildPluginManager implements BuildPluginManager {

  This is wholly dependent on Maven-Wagon, above.

  We could possibly use a flag on a particular Wagon to see whether it supports
  offline mode, and then test to see if the file-based basedir for an artifact
  repository works...if it doesn't work, we can mark that repository offline...

  OTOH, all offline-mode checks can probably be run from Wagon-based APIs.

** Maven-SCM

import org.apache.maven.api.services.VersionParser;
import org.apache.maven.model.version.ModelVersionParser;

import static org.apache.maven.internal.impl.Utils.nonNull;

/**
 * A wrapper class around a resolver version that works as model version parser as well.
 */
@Named
@Singleton
public class DefaultVersionParser implements VersionParser {
    private final ModelVersionParser modelVersionParser;

    @Inject

 can be offered to be opened together with the current project.
 problems with the current solution are:
 1. information is duplicate. once in POM's dependencies and once in the
 maven.multiproject.includes property.
 2. it works without problems only for projects with relative paths, e.g., from
 one CVS repository.. for projects from multiple SCM repositories it's harder
 to maintain the same relative links on all developer computers.