private final Collection<ProjectExecutionListener> listeners;

    CompoundProjectExecutionListener(Collection<ProjectExecutionListener> listeners) {
        this.listeners = listeners; // NB this is live injected collection
    }

    @Override
    public void beforeProjectExecution(ProjectExecutionEvent event) throws LifecycleExecutionException {
        for (ProjectExecutionListener listener : listeners) {

    private final Collection<MojoExecutionListener> listeners;

    CompoundMojoExecutionListener(Collection<MojoExecutionListener> listeners) {
        this.listeners = listeners; // NB this is live injected collection
    }

    public void beforeMojoExecution(MojoExecutionEvent event) throws MojoExecutionException {
        for (MojoExecutionListener listener : listeners) {

import org.apache.maven.extension.internal.CoreExports;

/**
 */
@Named
@Singleton
@Deprecated
public class DefaultArtifactFilterManager implements ArtifactFilterManager {

    // this is a live injected collection
    protected final List<ArtifactFilterManagerDelegate> delegates;

    protected Set<String> excludedArtifacts;

    private final Set<String> coreArtifacts;

    @Inject

    private final Logger logger = LoggerFactory.getLogger(getClass());

    private final ClassWorld world;

    private final ClassRealm containerRealm;

    // this is a live injected collection
    private final List<ClassRealmManagerDelegate> delegates;

    private final ClassRealm mavenApiRealm;

    /**

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.
In the next test that same "live implementation" will be used in a stub version instead.

Not all live services have stubs, but can be added as needed.
</body>

- we also seem to have information like the plugin lifecycle model that's buried inside the maven execution model
- we also seem to have artifact information tangled inside the plugin model
- we have to deal with scripting implementations (groovy, beanshell, ruby)
- we need to deal with a shared context for plugins, like the guarded mojos

  <offline>false</offline>
  -->

  <!-- pluginGroups
   | This is a list of additional group identifiers that will be searched when resolving plugins by their prefix, i.e.
   | when invoking a command line like "mvn prefix:goal". Maven will automatically add the group identifiers
   | "org.apache.maven.plugins" and "org.codehaus.mojo" if these are not already contained in the list.
   |-->
  <pluginGroups>
    <!-- pluginGroup

        return systemProperties;
    }

    /**
     * Sets the system properties to use for interpolation and profile activation. The system properties are collected
     * from the runtime environment like {@link System#getProperties()} and environment variables.
     *
     * @param systemProperties The system properties, may be {@code null}.
     * @return This context, never {@code null}.
     */

    }

    /**
     * Creates a string with all location details for the specified model problem. If the project identifier is
     * provided, the generated location will omit the model id and source information and only give line/column
     * information for problems originating directly from this POM.
     *
     * @param problem The problem whose location should be formatted, must not be {@code null}.

        assertEquals(toString(expectedList), toString(actualList));
    }

    private static String toString(List<String> lines) {
        StringBuilder sb = new StringBuilder();
        for (String line : lines) {
            sb.append(line).append('\n');
        }
        return sb.toString();
    }