define its own format and semantics. This was generally a properties format.
            <p>Since Maven 3.2.4, the type for this field has been changed to Properties to match the de-facto
            format.
            <p>Each toolchain defines its own properties names and semantics.
          </description>
        </field>
        <field>

     *
     * @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<>();

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

     *
     * @return the default classifier, or {@code null}.
     */
    @Nullable
    String getClassifier();

    /**
     * Specifies if the artifact already embeds its own dependencies.
     * This is the case for JEE packages or similar artifacts such as
     * WARs, EARs, etc.
     *
     * @return if the artifact's dependencies are included in the artifact
     */

import org.codehaus.plexus.classworlds.realm.ClassRealm;
import org.eclipse.aether.RepositorySystemSession;
import org.eclipse.aether.repository.RemoteRepository;
import org.slf4j.LoggerFactory;

// TODO the antrun plugin has its own configurator, the only plugin that does. might need to think about how that works
// TODO remove the coreArtifactFilterManager

/**
 * DefaultBuildPluginManager
 */
@Named
@Singleton

  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

            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,
            so this list does not contain all possible types.
          </description>
          <type>String</type>
          <defaultValue>jar</defaultValue>
        </field>

from the class loader that loaded the LogFactory class itself otherwise. This allows a copy of commons-logging.jar to be shared in a multiple class loader environment (such as a servlet container), but still allow each web application to provide its own LogFactory implementation, if it so desires. An instance of this class will then be created, and cached per class loader. The Default LogFactory Implementation The Logging Package APIs include a default LogFactory implementation class ( org.apache....

normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License. You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction,...

                addPathElement(JavaPathType.patchModule(moduleName), subdir);
                addToClasspath = false;
            }
            /*
             * If the test output directory provides some modules of its own, add them.
             * Except for this unusual case, tests should never be added to the module-path.
             */
            for (Map.Entry<Path, String> entry : testModules.getModuleNames().entrySet()) {