import java.util.Collection;
import java.util.HashSet;
import java.util.Set;

/**
 * Filter to only retain objects in the given scope or better. This implementation allows the accumulation of multiple
 * scopes and their associated implied scopes, so that the user can filter apply a series of implication rules in a
 * single step. This should be a more efficient implementation of multiple standard {@link ScopeArtifactFilter}
 * instances ORed together.

     * The returned list of versions is only dependent on the configured repositories and their contents.
     * The supplied request may also refer to a single concrete version rather than a version range.
     * In this case though, the result contains simply the (parsed) input version, regardless of the
     * repositories and their contents.
     *
     * @param artifact the artifact for which to resolve the versions

    void add(Problem.Severity severity, String message, int line, int column, Exception cause);

    /**
     * The next messages will be bound to this source. When calling this method again, previous messages keep
     * their source, but the next messages will use the new source.
     *
     * @param source a source
     */
    void setSource(String source);

    /**
     *
     * @return the collected Problems, never {@code null}

            Other values define only the prefix of classes/resources being exposed. Their binary name must be equal to the prefix or starting with the prefix (followed by "." or "$").

     *
     * @return A map of lifecycles, indexed on id
     */
    public Map<String, Lifecycle> getPhaseToLifecycleMap() {
        // If people are going to make their own lifecycles then we need to tell people how to namespace them correctly
        // so that they don't interfere with internally defined lifecycles.

        Map<String, Lifecycle> phaseToLifecycleMap = new HashMap<>();

                } else if (unknown) {
                    // More than one filtered value, and we don't know how to handle at least one of them.
                    // TODO: add a plugin mechanism for allowing plugin to specify their selection algorithm.
                    return Optional.empty();
                }
            }
        }
        if (classes & modules) {
            selected = getPathType(path);
        }

     * Maven-based resolution. In more detail, this method configures settings relevant for the processing of dependency
     * graphs, most other settings remain at their generic default value. Use the various setters to further configure
     * the session with authentication, mirror, proxy and other information required for your environment. At least,

 * </p>
 * <p>
 * There are several issues/discussions regarding how "aggregator" plugins should be handled.
 * Read for instance http://docs.codehaus.org/display/MAVEN/Deterministic+Lifecycle+Planning
 * </p>
 * <p>
 * In their current implementation they are "bolted" onto the lifecycle by separating them
 * into TaskSegments. This class represents the execution context of one such task segment.
 * </p>
 * <p>

  they are snapshot versions; artifact deployment cannot take place; certain
  types of tests cannot be setup, since the container used to run them cannot be
  reached or started.

  All of these operations will produce their own unique errors in the absence of
  a coordinated offline strategy. In addition, efforts to unite these failing
  behaviors behind a consistent user interface is much, much more difficult if

      <releases>
        <enabled>false</enabled>
      </releases>
    </repository>
  </repositories>
  <distributionManagement>
    <!-- Site omitted - each project must provide their own -->
    <repository>
      <id>apache.releases</id>
      <name>Apache Release Distribution Repository</name>
      <url>scp://minotaur.apache.org/www/www.apache.org/dist/maven-repository</url>
    </repository>