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

     * local repository manager needs to be configured to make session be able to create session instance.
     *
     * @return SessionBuilder configured with minimally required things for "Maven-based resolution". At least LRM must
     * be set on builder to make it able to create session instances.
     */
    @Override
    public SessionBuilder get() {

         * transformation however contradicts the other use case of precisely obeying the repository's layout. The below
         * flag tries to detect which use case applies to make both plugins happy.
         */
        realLocalRepo = (layout instanceof DefaultRepositoryLayout) && "local".equals(delegate.getId());
    }

    public LocalRepository getRepository() {
        return repo;

 * There is still the issue of having to run the lifecycle in order to find all the compile source roots and resource
 * directories but I hope to take care of this during the Maven 4.0 release (jvz).
 * </p>
 */
public class MavenProject implements Cloneable {

    private static final Logger LOGGER = LoggerFactory.getLogger(MavenProject.class);

import org.junit.jupiter.api.Test;

import static org.junit.jupiter.api.Assertions.assertEquals;

/**
 * A test which demonstrates maven's recursive inheritance where
 * we are testing to make sure that elements stated in a model are
 * not clobbered by the same elements elsewhere in the lineage.
 *
 */
@Deprecated
class ProjectInheritanceTest extends AbstractProjectInheritanceTestCase {

          <description>
            Defines a default phase to bind a Mojo execution to if the user does not explicitly set a phase in the POM.
            &lt;p>&lt;b>Note:&lt;/b> This will not automagically make a Mojo run when the plugin declaration is added
            to the POM. It merely enables the user to omit the {@code &lt;phase&gt;} element from the
            surrounding {@code &lt;execution&gt;} element.&lt;/p>

    static {
        Collection<String> translatedPrefixes = new HashSet<>();

        // MNG-1927, MNG-2124, MNG-3355:
        // If the build section is present and the project directory is non-null, we should make
        // sure interpolation of the directories below uses translated paths.
        // Afterward, we'll double back and translate any paths that weren't covered during interpolation via the
        // code below...

                    .pluginRepositories(List.of(centralWithNoUpdate))
                    .build();
        }

        // for the special case of a drive-relative Windows path, make sure it's absolute to save plugins from trouble
        String localRepository = effective.getLocalRepository();
        if (localRepository != null && !localRepository.isEmpty()) {

    // 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
    // from the plugin.xml inside a plugin.
    //

     * Adapt a {@link MavenExecutionRequest} to a {@link Settings} object for use in the Maven core.
     * We want to make sure that what is ask for in the execution request overrides what is in the settings.
     * The CLI feeds into an execution request so if a particular value is present in the execution request
     * then we will take that over the value coming from the user settings.
     */