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.

    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>

      <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>

                } 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);
        }

     * repository. It is worth to point out that merging does not simply choose one of the input repositories and
     * discards the others but actually combines their possibly different policies.
     *
     * @param repositories The original repositories, may be {@code null}.
     * @return The effective repositories or {@code null} if the input was {@code null}.
     */