* artifactId, and version for the plugin; at times, the goal name for which
 * execution failed; a message detailing the problem; the ClassRealm used to
 * look up the plugin; and the Plexus exception that caused this error.
 *
 *
 */
public class PluginContainerException extends PluginManagerException {

    private ClassRealm pluginRealm;

    }

    public void execute(MavenSession session) {
        lifecycleStarter.execute(session);
    }

    // These methods deal with construction intact Plugin object that look like they come from a standard
    // <plugin/> block in a Maven POM. We have to do some wiggling to pull the sources of information
    // together and this really shows the problem of constructing a sensible default configuration but

                                + "plugin(s) that have goals not marked as thread-safe to support parallel execution.",
                        "While this /may/ work fine, please look for plugin updates and/or "
                                + "request plugins be made thread-safe.",
                        "If reporting an issue, report it against the plugin in question, not against Apache Maven.")) {

        boolean isWindows = actualOsName.contains(FAMILY_WINDOWS);
        boolean is9x = false;
        boolean isNT = false;
        if (isWindows) {
            // there are only four 9x platforms that we look for
            is9x = (actualOsName.contains("95")
                    || actualOsName.contains("98")
                    || actualOsName.contains("me")
                    // wince isn't really 9x, but crippled enough to

            goal = goal.substring(0, executionIdx);
        }

        injectPluginDeclarationFromProject(plugin, project);

        // If there is no version to be found then we need to look in the repository metadata for
        // this plugin and see what's specified as the latest release.
        //
        if (plugin.getVersion() == null) {
            resolvePluginVersion(plugin, session, project);

        Xpp3Dom dom = null;

        // ----------------------------------------------------------------------
        // I would like to be able to look up the Mojo object using a key but
        // we have a limitation in modello that will be remedied shortly. So
        // for now I have to iterate through and see what we have.

    // can be passed back so that the default configuration information can be populated.
    //
    // We need to know the specific version so that we can look up the right version of the plugin descriptor
    // which tells us what the default configuration is.
    //

    /**

                        }
                    }
                }
                // if not then I need to grab the mojo descriptor and look at the phase that is specified
                else {
                    for (String goal : execution.getGoals()) {
                        MojoDescriptor mojoDescriptor = pluginManager.getMojoDescriptor(

import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertThrows;
import static org.junit.jupiter.api.Assertions.assertTrue;

// It would be cool if there was a hook that I could use to set up a test environment.
// I want to set up a local/remote repositories for testing but I don't want to have
// to change them when I change the layout of the repositories. So I want to generate

        this.lookup = requireNonNull(lookup);
        this.defaultLifeCycles = requireNonNull(defaultLifeCycles);
    }

    // These methods deal with construction intact Plugin object that look like they come from a standard
    // <plugin/> block in a Maven POM. We have to do some wiggling to pull the sources of information
    // together and this really shows the problem of constructing a sensible default configuration but