* unique within a single POM. Upon multiple declarations, 2.x just kept the last one but retained the order of
         * the first occurrence. So when we're in lenient/compat mode, we have to deal with such broken POMs and mimic
         * the way 2.x works. When we're in strict mode, the removal of duplicates just saves other merging steps from
         * aftereffects and bogus error messages.
         */

     */
    public Lifecycle get(String phase) {
        return getPhaseToLifecycleMap().get(phase);
    }

    /**
     * We use this to map all phases to the lifecycle that contains it. This is used so that a user can specify the
     * phase they want to execute and we can easily determine what lifecycle we need to run.
     *
     * @return A map of lifecycles, indexed on id
     */

 * anywhere else in the lineage. We are just making sure that values
 * down in the lineage are bubbling up where they should.
 *
 */
@Deprecated
class ProjectInheritanceTest extends AbstractProjectInheritanceTestCase {
    // ----------------------------------------------------------------------
    //
    // p1 inherits from p0
    // p0 inherits from super model
    //
    // or we can show it graphically as:
    //

                    }
                    cycle.removeLast();
                    stateMap.put(v, DfsState.VISITED);
                } else if (state == DfsState.VISITING) {
                    // we are already visiting this vertex, this mean we have a cycle
                    int pos = cycle.lastIndexOf(v);
                    List<String> ret = cycle.subList(pos, cycle.size());
                    ret.add(v);
                    return ret;

            // There is no need to check if the build has created any outputs, see MNG-2222.
            boolean projectCompiledDuringThisSession =
                    project.hasLifecyclePhase("compile") && COMPILE_PHASE_TYPES.contains(type);

            // Check if the project is part of the session (not filtered by -pl, -rf, etc). If so, we check

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

    // We are going to take the project packaging and find all plugin in the default lifecycle and create

    currently wrong for execution.

    <<NOTE:>> Do we want to fail when we cannot bind a mojo to the lifecycle
    because of offline/online status? That would probably indicate that the user
    was trying to do something they cannot succeed at for now...so we probably

        // 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...
        translatedPrefixes.add("build.directory");

        // The root artifact may, or may not be resolved so we need to check before we attempt to resolve.
        // This is often an artifact like a POM that is taken from disk and we already have hold of the
        // file reference. But this may be a Maven Plugin that we need to resolve from a remote repository
        // as well as its dependencies.

            }
            candidateSource = ModelSource.fromPath(candidateModel.getPomFile());
        }

        //
        // TODO jvz Why isn't all this checking the job of the duty of the workspace resolver, we know that we
        // have a model that is suitable, yet more checks are done here and the one for the version is problematic
        // before because with parents as ranges it will never work in this scenario.
        //