*   <li>version circular dependencies</li>
 *   <li>missing artifacts</li>
 *   <li>network/transfer errors</li>
 *   <li>file system errors: permissions</li>
 * </ul>
 *
 * TODO carlos: all these possible has*Exceptions and get*Exceptions methods make the clients too
 *       complex requiring a long list of checks, need to create a parent/interface/encapsulation
 *       for the types of exceptions
 */
@Deprecated

  <description>Maven is a project development management and comprehension tool. Based on the concept of a project object model: builds, dependency management, documentation creation, site publication, and distribution publication are all controlled from the declarative file. Maven can be extended by plugins to utilise a number of other development tools for reporting or the build process.</description>
  <url>http://maven.apache.org/maven2/</url>
  <issueManagement>

  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

  In all but trivial examples, SCM operations cannot complete without
  having access to the versioning server. Therefore, it is assumed that

import org.eclipse.aether.impl.scope.ScopeManagerConfiguration;
import org.eclipse.aether.internal.impl.scope.ScopeManagerDump;

import static org.eclipse.aether.impl.scope.BuildScopeQuery.all;
import static org.eclipse.aether.impl.scope.BuildScopeQuery.byBuildPath;
import static org.eclipse.aether.impl.scope.BuildScopeQuery.byProjectPath;
import static org.eclipse.aether.impl.scope.BuildScopeQuery.select;

 * </p>
 * <p>
 * Wise voices have suggested that maybe aggregators shouldn't be bound to the ordinary
 * lifecycle at all, in which case we wouldn't be needing this class at all ( and
 * ProjectBuildList.getByTaskSegments). Or maybe they should be introduced in the calculation
 * of the execution plan instead, which seems much nicer.
 * </p>
 * <p>

    // together and this really shows the problem of constructing a sensible default configuration but
    // it's all encapsulated here so it appears normalized to the POM builder.

    // We are going to take the project packaging and find all plugins in the default lifecycle and create
    // fully populated Plugin objects, including executions with goals and default configuration taken

import org.apache.maven.api.annotations.Experimental;
import org.apache.maven.api.annotations.Nonnull;
import org.apache.maven.api.model.Model;
import org.apache.maven.api.model.Profile;

/**
 * Result of a project build call.
 *
 * @since 4.0.0
 */
@Experimental
public interface ModelBuilderResult {

    /**
     * Gets the sequence of model identifiers that denote the lineage of models from which the effective model was

 * @since 4.0.0
 * @see org.apache.maven.api.services.DependencyResolver
 * @see DependencyScope
 */
@Experimental
@Immutable
public interface PathScope extends ExtensibleEnum {

    // TODO: what if I simply want all dependencies ?
    @Nonnull
    ProjectScope projectScope();

    @Nonnull
    Set<DependencyScope> dependencyScopes();

    PathScope MAIN_COMPILE = pathScope(
            "main-compile",

    if match is found, the toolchain instance is made available to other Maven plugins.</p>
    <p>With {@code jdk} toolchain, for example, instead of being stuck with the JDK used to run Maven, all plugins can use
    the same other JDK instance without hardcoding absolute paths into the {@code pom.xml}
    and without configuring every plugin that require path to JDK tools.</p>

    private Set<Artifact> artifactDependencies;

    private ArtifactRepository localRepository;

    private List<ArtifactRepository> remoteRepositories;

    // This is like a filter but overrides all transitive versions
    private Map managedVersionMap;

    /** result type - flat list; the default */
    private boolean asList = true;

    /** result type - dirty tree */
    private boolean asDirtyTree = false;