}
        }

        doExecute(session, mojoExecution, dependencyContext);
    }

    /**
     * Aggregating mojo executions (possibly) modify all MavenProjects, including those that are currently in use
     * by concurrently running mojo executions. To prevent race conditions, an aggregating execution will block
     * all other executions until finished.

  <groupId>org.apache.maven.its.mng2591</groupId>
  <artifactId>parent</artifactId>
  <version>1.0</version>
  <packaging>pom</packaging>

  <name>Maven Integration Test :: MNG-2591</name>
  <description>
    Test aggregation of list configuration items for build plugins when using
    'combine.children=append' attribute.
  </description>

  <modules>
    <module>subproject</module>
  </modules>

  <build>
    <pluginManagement>

        return pluginManager.getMojoDescriptor(
                plugin, goal, project.getRemotePluginRepositories(), session.getRepositorySession());
    }

    // TODO take repo mans into account as one may be aggregating prefixes of many
    // TODO collect at the root of the repository, read the one at the root, and fetch remote if something is missing
    // or the user forces the issue

                boolean aggregating = mojoDescriptor.isAggregator() || !mojoDescriptor.isProjectRequired();

                if (currentSegment == null || currentSegment.isAggregating() != aggregating) {
                    currentSegment = new TaskSegment(aggregating);
                    taskSegments.add(currentSegment);
                }

        private final Set<String> resolve;

        private boolean aggregating;

        private final int hashCode;

        public CacheKey(
                MavenProject project,
                List<RemoteRepository> repositories,
                Collection<String> scopesToCollect,
                Collection<String> scopesToResolve,
                boolean aggregating,
                RepositorySystemSession session) {

ProjectDependencyGraphStub

Since they define the primary structure of the project/build.

The stubs define three top-level targets that are defined in  LifecycleTaskSegmentCalculatorStub;
clean, aggr and install. "aggr" is an aggregating task while clean and install are lifecyclephases.
There will be three items in the task list for this dataset.

The stubs also exist at different "levels", where one test might wire stubs into a specific live implementation.

 * into TaskSegments. This class represents the execution context of one such task segment.
 * </p>
 * <p>
 * Wise voices have suggested that maybe aggregators shouldn't be bound to the ordinary
 * lifecycle at all, in which case we wouldn't be needing this class at all ( and
 * ProjectBuildList.getByTaskSegments). Or maybe they should be introduced in the calculation

                        ModelProblem problem = new org.apache.maven.internal.impl.model.DefaultModelProblem(
                                "Child module " + moduleFile + " of " + pomFile + " forms aggregation cycle " + buffer,
                                ModelProblem.Severity.ERROR,
                                ModelProblem.Version.BASE,
                                model,
                                -1,

  instance, just as definition of the active profile from the command-line
  should result in similar modification. This object is not meant to be
  static within the build process, but rather to be setup as an aggregation of
  all settings-related information passed into the system.

** Control over downloads

  Find the control point for m2 using maven-wagon. At this point, inject

your rights to work written entirely by you; rather, the intent is to
exercise the right to control the distribution of derivative or
collective works based on the Program.

In addition, mere aggregation of another work not based on the Program
with the Program (or with a work based on the Program) on a volume of a
storage or distribution medium does not bring the other work under the
scope of this License.