}
            trace = trace.getParent();
        }
        return collectStepTrace;
    }

    /**
     * The event "artifact resolved" if fired WHENEVER an artifact is resolved, BUT it happens also when an artifact
     * descriptor (model, the POM) is being built, and parent (and parent of parent...) is being asked for. Hence, this

     * by concurrently running mojo executions. To prevent race conditions, an aggregating execution will block
     * all other executions until finished.
     * We also lock on a given project to forbid a forked lifecycle to be executed concurrently with the project.
     * TODO: ideally, the builder should take care of the ordering in a smarter way

    }

    /**
     * We are interested in project success events, in which case we call
     * the {@link #installIntoProjectLocalRepository(MavenProject)} method.
     * The mojo started event is also captured to determine the lifecycle
     * phases the project has been through.
     *
     * @param event the execution event
     */
    private void processEvent(ExecutionEvent event) {

     * For example, resolves "[3.8,4.0)" to "3.8", "3.8.1", "3.8.2".
     * The returned list of versions is only dependent on the configured repositories and their contents.
     * The supplied request may also refer to a single concrete version rather than a version range.
     * In this case though, the result contains simply the (parsed) input version, regardless of the
     * repositories and their contents.
     *

            String expectedChecksum = new String(bytes, StandardCharsets.UTF_8);

            // remove whitespaces at the end
            expectedChecksum = expectedChecksum.trim();

            // check for 'ALGO (name) = CHECKSUM' like used by openssl
            if (expectedChecksum.regionMatches(true, 0, "MD", 0, 2)
                    || expectedChecksum.regionMatches(true, 0, "SHA", 0, 3)) {

     * of the child. The general idea is to adjust inherited URLs to match the project layout (in SCM).
     *
     * <p>This calculation is only a heuristic based on our conventions.
     * In detail, the algo relies on the following assumptions: <ul>
     * <li>The parent uses aggregation and refers to the child via the modules section</li>
     * <li>The module path to the child is considered to

                scenario("Selected project with also make dependencies")
                        .activeRequiredProjects(MODULE_C_2)
                        .makeBehavior(REACTOR_MAKE_UPSTREAM)
                        .expectResult(PARENT_MODULE, MODULE_C, MODULE_A, MODULE_B, MODULE_C_2),
                scenario("Selected project with also make dependents")
                        .activeRequiredProjects(MODULE_B)

     * </ul>
     * @throws DuplicateProjectException if any projects are duplicated by id
     */
    // MAVENAPI FIXME: the DAG used is NOT only used to represent the dependency relation,
    // but also for <parent>, <build><plugin>, <reports>. We need multiple DAG's
    // since a DAG can only handle 1 type of relationship properly.
    // Use case:  This is detected as a cycle:

 * Generic implementation of version comparison.
 * </p>
 * <p>
 * Features:
 * <ul>
 * <li>mixing of '<code>-</code>' (hyphen) and '<code>.</code>' (dot) separators,</li>
 * <li>transition between characters and digits also constitutes a separator:
 *     <code>1.0alpha1 =&gt; [1, [alpha, 1]]</code></li>
 * <li>unlimited number of version components,</li>
 * <li>version components in the text can be digits or strings,</li>

            }
        }

        result.setArtifactResolutionNodes(set);

        return result;
    }

    /**
     * Get the map of managed versions, removing the originating artifact if it is also in managed versions
     *
     * @param originatingArtifact artifact we are processing
     * @param managedVersions original managed versions
     */
    private ManagedVersionMap getManagedVersionsMap(