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

import org.eclipse.aether.util.artifact.ArtifactIdUtils;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

/**
 * An implementation of a workspace reader that knows how to search the Maven reactor for artifacts, either as packaged
 * jar if it has been built, or only compile output directory if packaging hasn't happened yet.
 *
 */
@Named(ReactorReader.HINT)
@SessionScoped

        if (extensionRecord == null) {
            ClassRealm extensionRealm = classRealmManager.createExtensionRealm(plugin, toAetherArtifacts(artifacts));

            // TODO figure out how to use the same PluginDescriptor when running mojos

            PluginDescriptor pluginDescriptor = null;
            if (plugin.isExtensions() && !artifacts.isEmpty()) {

     * consumer project.
     * <p>
     * Note: This property is about "build path", whatever it means in the scope of the consumer project. It is NOT
     * about Java classpath or anything alike. How artifact is being consumed depends heavily on the consumer project.
     * Resolver is and will remain agnostic of consumer project use cases.
     */
    public static final String CONSTITUTES_BUILD_PATH = "constitutesBuildPath";

                }
                if (selected == null) {
                    selected = type;
                } 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();
                }
            }

    // <plugin/> block in a Maven POM. We have to do some wiggling to pull the sources of information
    // 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.

+-----+
${maven.home}
     |
     +--- maven.properties
+-----+

* Group configuration

 As far as properties go for an entire build the maven.properties could be placed at
 the top of the group but I'm not really sure how this might work. There could probably
 also be a directory for plugins.xml and maven.properties.

* Project configuration

 At the project level all configuration is achieved by tweaking the POM. One of the differences between

      <artifactId>maven-di</artifactId>
    </dependency>
    <dependency>
      <groupId>org.apache.maven</groupId>
      <artifactId>maven-model</artifactId>
    </dependency>
    <!-- Remove the following two deps to see how to remove Settings from the core -->
    <dependency>
      <groupId>org.apache.maven</groupId>
      <artifactId>maven-settings</artifactId>
    </dependency>
    <dependency>
      <groupId>org.apache.maven</groupId>

 * under the License.
 */
package org.apache.maven.artifact.handler;

/**
 * An artifact handler contains information explaining how an artifact plugs into the Maven build:<ul>
 * <li>Information needed to find the artifact file in a repository including extension and classifier</li>
 * <li>Information on how to use the artifact as a dependency: whether to add it to the classpath, whether to load its
 * dependencies transitively</li>
 * </ul>
 *

import org.apache.maven.api.annotations.Nonnull;
import org.apache.maven.api.model.PluginContainer;

/**
 * Interface representing a Maven project packaging.
 * <p>
 * TODO: define how to plug in new packaging definitions using the SPI.
 *   the packaging are currently defined by Maven 3 {@code Provider<LifecycleMapping>}
 *
 * @since 4.0.0
 */
@Experimental
@Immutable