String DEFAULT_REMOTE_REPO_URL = MavenRepositorySystem.DEFAULT_REMOTE_REPO_ID;

    Artifact createArtifact(String groupId, String artifactId, String version, String packaging);

    Artifact createArtifact(String groupId, String artifactId, String version, String scope, String type);

    Artifact createProjectArtifact(String groupId, String artifactId, String version);

  <modelVersion>4.0.0</modelVersion>
  <groupId>com.google.guava</groupId>
  <artifactId>guava-parent</artifactId>
  <version>999.0.0-HEAD-android-SNAPSHOT</version>
  <packaging>pom</packaging>
  <name>Guava Maven Parent</name>
  <description>Parent for guava artifacts</description>
  <url>https://github.com/google/guava</url>
  <properties>
    <!--

  <modelVersion>4.0.0</modelVersion>
  <groupId>com.google.guava</groupId>
  <artifactId>guava-parent</artifactId>
  <version>999.0.0-HEAD-jre-SNAPSHOT</version>
  <packaging>pom</packaging>
  <name>Guava Maven Parent</name>
  <description>Parent for guava artifacts</description>
  <url>https://github.com/google/guava</url>
  <properties>
    <!--

    }

    @Override
    public Artifact createArtifact(String groupId, String artifactId, String version, String packaging) {
        return artifactFactory.createBuildArtifact(groupId, artifactId, version, packaging);
    }

    @Override
    public Artifact createArtifactWithClassifier(
            String groupId, String artifactId, String version, String type, String classifier) {

        </field>
        <field>
          <name>packaging</name>
          <version>4.0.0+</version>
          <description>
            The type of artifact this project produces, for example {@code jar},
              {@code war},
              {@code ear},
              {@code pom}.
            Plugins can create their own packaging, and
            therefore their own packaging types,

 * the {@code /project/modules/module} elements of the POM in the aggregator project.
 * Note that the aggregator project is required to have a {@code pom} packaging.</p>
 *
 * <p><dfn>Project inheritance</dfn> defines a parent-child relationship between projects.
 * The <dfn>child project</dfn> inherits all the information from the <dfn>parent project</dfn>
 * POM.</p>
 *
 */

            <type>ActivationFile</type>
          </association>
        </field>
        <field>
          <name>packaging</name>
          <version>1.2.0+</version>
          <type>String</type>
          <description>
            Specifies that this profile will be activated based on the project's packaging.
          </description>
        </field>
        <field>
          <name>condition</name>

     * <ul>
     *   <li>The project's artifacts ({@link Project#getArtifacts()}):
     *     <ul>
     *       <li>The POM artifact (always present)</li>
     *       <li>The main project artifact (if applicable based on packaging)</li>
     *     </ul>
     *   </li>
     *   <li>All attached artifacts in the order they were attached</li>
     * </ul>
     * The contents depend on the current lifecycle phase when this method is called, as artifacts

    Language requireLanguage(@Nonnull String id);

    /**
     * Obtain the {@link Packaging} from the specified {@code id}.
     * <p>
     * Shortcut for {@code getService(PackagingRegistry.class).require(...)}.
     *
     * @see org.apache.maven.api.services.PackagingRegistry#require(String)
     */
    @Nonnull
    Packaging requirePackaging(@Nonnull String id);

    /**

is widely used among developers working in that language.

  The "System Libraries" of an executable work include anything, other
than the work as a whole, that (a) is included in the normal form of
packaging a Major Component, but which is not part of that Major
Component, and (b) serves only to enable use of the work with that
Major Component, or to implement a Standard Interface for which an