package org.apache.maven.artifact;

import org.codehaus.plexus.component.repository.exception.ComponentLookupException;

/**
 * Exception which is meant to occur when a layout specified for a particular
 * repository doesn't have a corresponding {@link org.apache.maven.artifact.repository.layout.ArtifactRepositoryLayout}
 * component in the current container.
 *
 */
@Deprecated

        }

        return repository;
    }

    private boolean isLocalRepository(ArtifactRepository repository) {
        // unfortunately, the API doesn't allow to tell a remote repo and the local repo apart...
        return "local".equals(repository.getId());
    }

        // snapshot timestamp, or some other timestamp later encoded into the metadata.
        // TODO this needs to be repeated here so the merging doesn't interfere with the written metadata
        //  - we'd be much better having a pristine input, and an ongoing metadata for merging instead

        Map<ArtifactRepository, Metadata> previousMetadata = new HashMap<>();

                        }
                    }
                    break;
                }
            }
        }

        if (dom != null) {
            // make a copy so the original in the POM doesn't get messed with
            dom = new Xpp3Dom(dom);
        }

        return dom;
    }

    public MavenProject getExecutionProject() {

    server processes which work by conversing over a port may fail.

  * Not all "remote" repositories will fail. Specifically, if the remote
    repo uses the file:// protocol, and it doesn't refer to a shared
    filesystem, it will continue to be available.

  The question remaining is: Which level of offline mode will we support? It
  seems reasonable to assume that users will be able to tell when localhost is

  <artifactId>maven-it-it0052</artifactId>
  <version>1.0</version>
  <packaging>jar</packaging>

  <name>Maven Integration Test :: it0052</name>
  <description>Test that source attachment doesn't take place when -DperformRelease=true is missing.</description>

  <!-- NOTE: Use stub versions of the core plugins referenced by the build -->
  <build>
    <pluginManagement>
      <plugins>
        <plugin>

  <artifactId>test</artifactId>
  <version>1.0-SNAPSHOT</version>

  <name>Maven Integration Test :: MNG-3821</name>
  <description>
    Verify that using the same id for executions/reportsets of different plugins doesn't blow up the project builder.
  </description>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.its.plugins</groupId>
        <artifactId>maven-it-plugin-a</artifactId>

    /**
     * Returns a filter for only the core artifacts.
     *
     * @return the artifact filter
     */
    ArtifactFilter getCoreArtifactFilter();

    /**
     * Exclude an extension artifact (doesn't affect getArtifactFilter's result, only getExtensionArtifactFilter).
     *
     * @param artifactId an artifact id
     * @deprecated use {@code META-INF/maven/extension.xml} to define artifacts exported by Maven core and plugin

  maven occur, the maven inheritance model must be pinned against a particular
  modelVersion. This is required so that a change from modelVersion 4.0.0 to
  4.1.0 doesn't cause compatibility problems with users who have not upgraded
  their projects. It also allows for a certain amount of legacy support into the
  future. Therefore, we should rename this file from pom.xml in the maven-core

         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <!-- Shared parent. Doesn't define a lot of things about Apache like general mailing lists, but does
       define the settings common to all projects at Apache -->
  <groupId>org.apache</groupId>
  <artifactId>apache</artifactId>
  <version>1</version>