session.setProjectDependencyGraph(new ProjectDependencyGraph() {
            @Override
            public List<MavenProject> getUpstreamProjects(MavenProject project, boolean transitive) {
                return Collections.emptyList();
            }

            @Override
            public List<MavenProject> getAllProjects() {
                return session.getAllProjects();
            }

                && (scopesToResolve == null || scopesToResolve.isEmpty())) {
            return resolved;
        }

        /*

        Logic for transitive global exclusions

        List<String> exclusions = new ArrayList<String>();

        for ( Dependency d : project.getDependencies() )
        {
            if ( d.getExclusions() != null )
            {

                        .makeBehavior(REACTOR_MAKE_DOWNSTREAM)
                        .expectResult(MODULE_C_2),
                scenario("Excluding an also make dependency from selectedProject does take its transitive dependency")
                        .activeRequiredProjects(MODULE_C_2)
                        .inactiveRequiredProjects(MODULE_B)
                        .makeBehavior(REACTOR_MAKE_UPSTREAM)

     * This is the behavior of Maven 3.
     */
    String JAR = "jar";

    /**
     * Artifact type name for a fat-JAR file that can be only on the class path.
     * The fat-JAR is a self-contained JAR and its transitive dependencies will not be resolved, if any.
     * This type is new in Maven 4.
     */
    String FATJAR = "fatjar";

    /**
     * Artifact type name for a JAR file to unconditionally place on the class path.

    // bProject -> cProject
    //        | -> dProject
    //        | -> eProject
    // cProject -> dProject
    //        | -> eProject
    // dProject -> eProject
    //
    // When getting the non-transitive, downstream projects of aProject with a whitelist of aProject, dProject,
    // and eProject, we expect to get dProject, and eProject with no duplicates.

 files.

 For many of the more advanced features in Maven2 it is critical that POMs be available in the local repository.
 Features like transitive dependencies and the new parent specification mechanism. The problem we run into is
 that currently we have information about a project scattered across the project.xml and the

   * <p>Note that if {@code a.encloses(b)}, then {@code b.contains(v)} implies {@code
   * a.contains(v)}, but as the last two examples illustrate, the converse is not always true.
   *
   * <p>Being reflexive, antisymmetric and transitive, the {@code encloses} relation defines a
   * <i>partial order</i> over ranges. There exists a unique {@linkplain Range#all maximal} range

            associated with a Maven project can lack a file. As such, this annotation is meant for Mojos that only
            want to analyze the set of transitive dependencies, in particular during early lifecycle phases where
            full dependency resolution might fail due to projects which haven't been built yet.
          </description>
        </field>
        <field>

        assertTrue(zebra.compareTo(greek) < 0);
    }

    /**
     * Test <a href="https://issues.apache.org/jira/browse/MNG-5568">MNG-5568</a> edge case
     * which was showing transitive inconsistency: since A &gt; B and B &gt; C then we should have A &gt; C
     * otherwise sorting a list of ComparableVersions() will in some cases throw runtime exception;

    directedGraph.putEdge(N1, N2);
    directedGraph.putEdge(N1, N3);
    directedGraph.putEdge(N2, N3);
    directedGraph.addNode(N4);

    // the above graph is its own transitive closure
    MutableGraph<Integer> expectedClosure = GraphBuilder.directed().allowsSelfLoops(true).build();
    expectedClosure.putEdge(N1, N2);
    expectedClosure.putEdge(N1, N3);
    expectedClosure.putEdge(N2, N3);