.collect(Collectors.joining(", ")));
                        }
                        step.mojos.values().stream()
                                .flatMap(m -> m.values().stream())
                                .forEach(mojo -> mojo(writer, mojo));
                    });
        }

        writer.accept("=======================================================================");
    }

    public ProjectBuildList(List<ProjectSegment> items) {
        this.items = Collections.unmodifiableList(items);
    }

    // TODO Optimize; or maybe just rewrite the whole way aggregating mojos are being run.
    /**
     * Returns aProjectBuildList that contains only items for the specified taskSegment
     * @param taskSegment the requested task segment
     * @return a project build list for the supplied task segment

    }

    /**
     * Post-processes the effective configuration for the specified mojo execution. This step discards all parameters
     * from the configuration that are not applicable to the mojo and injects the default values for any missing
     * parameters.
     *
     * @param mojoExecution The mojo execution whose configuration should be finalized, must not be {@code null}.
     */

                new File(delegate.getBasedir()),
                (layout != null) ? layout.getClass().getSimpleName() : "legacy");

        /*
         * NOTE: "invoker:install" vs "appassembler:assemble": Both mojos use the artifact installer to put an artifact
         * into a repository. In the first case, the result needs to be a proper local repository that one can use for

    /**
     * Returns the original project being built when the input project is a forked project.
     * During certain lifecycle phases, particularly for aggregator mojos, Maven may create
     * a forked project (a copy of the original project) to execute a subset of the lifecycle.
     * This method allows retrieving the original project that initiated the build.
     *

- 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
- we need to deal with plugins as core application logic which can also interact with plugins

* Along with this comes the testing strategies that make this work
* The repository model where plugins can be stored and cataloged

                    validateVersion(
                            prefix, "version", problems, errOn30, Version.V20, d.getVersion(), d.getManagementKey(), d);

                    /*
                     * Extensions like Flex Mojos use custom scopes like "merged", "internal", "external", etc. In
                     * order to not break backward-compat with those, only warn but don't error out.
                     */

import org.apache.maven.api.annotations.Nonnull;

/**
 * This annotation will mark your class as a Mojo, which is the implementation of a goal in a Maven plugin.
 * <p>
 * The mojo can be annotated with {@code org.apache.maven.api.di.*} annotations to
 * control the lifecycle of the mojo itself, and to inject other beans.
 * </p>
 * <p>
 * The mojo class can also be injected with an {@link Execute} annotation to specify a
 * forked lifecycle.
 * </p>

    private final MojoDescriptor mojo;

    public PluginParameterException(MojoDescriptor mojo, List<Parameter> parameters) {
        super(
                mojo.getPluginDescriptor(),
                "The parameters " + format(parameters) + " for goal " + mojo.getRoleHint() + " are missing or invalid");

        this.mojo = mojo;

        this.parameters = parameters;
    }

    private final Mojo mojo;

    private final Throwable cause;

    public MojoExecutionEvent(MavenSession session, MavenProject project, MojoExecution mojoExecution, Mojo mojo) {
        this(session, project, mojoExecution, mojo, null);
    }

    public MojoExecutionEvent(
            MavenSession session, MavenProject project, MojoExecution mojoExecution, Mojo mojo, Throwable cause) {