for (ExecutionPlanItem executionPlanItem : planItem) {
            result.add(executionPlanItem.getMojoExecution());
        }
        return result;
    }

    /**
     * Get set of plugins having a goal/mojo used but not marked @threadSafe
     *
     * @return the set of plugins (without info on which goal is concerned)
     */
    public Set<Plugin> getNonThreadSafePlugins() {

     * Creates a coordinate out of string that is formatted like:
     * {@code <groupId>:<artifactId>[:<extension>[:<classifier>]]:<version>}
     *
     * @param session the session.
     * @param coordinateString the string having "standard" coordinate.
     * @return an {@code ArtifactCoordinate}, never {@code null}
     * @throws IllegalArgumentException if {@code session} is null or invalid
     */
    @Nonnull

  OTOH, all offline-mode checks can probably be run from Wagon-based APIs.

** Maven-SCM

  In all but trivial examples, SCM operations cannot complete without
  having access to the versioning server. Therefore, it is assumed that
  any SCM-related activity will be unavailable when m2 is in offline
  mode.

** Maven-Core

     * {@code <groupId>:<artifactId>[:<extension>[:<classifier>]]:<version>}.
     * <p>
     * Shortcut for {@code getService(ArtifactFactory.class).create(...)}.
     *
     * @param coordString the string having "standard" coordinate.
     * @return coordinate used to point to the artifact
     *
     * @see org.apache.maven.api.services.ArtifactCoordinateFactory#create(Session, String)
     */
    @Nonnull

 * all components from this class, and the upfront construction taken care of entirely by the {@link ProjectBuilder}.
 * There is still the issue of having to run the lifecycle in order to find all the compile source roots and resource
 * directories but I hope to take care of this during the Maven 4.0 release (jvz).
 * </p>
 */
public class MavenProject implements Cloneable {

        <field>
          <name>executions</name>
          <version>4.0.0+</version>
          <description>Multiple specifications of a set of goals to execute during the build
            lifecycle, each having (possibly) a different configuration.</description>
          <association>
            <type>PluginExecution</type>
            <multiplicity>*</multiplicity>
          </association>
        </field>

        File f2 = getTestFile("src/test/resources/projects/grandchild-check/child/grandchild/pom.xml");

        getProject(f1);

        // it's the building of the grandchild project, having already cached the child project
        // (but not the parent project), which causes the problem.
        getProject(f2);
    }

    @Disabled("Maven 4 does not allow duplicate plugin declarations")
    @Test

        // snapshot timestamp, or some other timestamp later encoded into the metadata.
        // TODO this needs to be repeated here so the merging doesn't interfere with the written metadata
        //  - we'd be much better having a pristine input, and an ongoing metadata for merging instead

        Map<ArtifactRepository, Metadata> previousMetadata = new HashMap<>();
        ArtifactRepository selected = null;

 * it delegates to other components that potentially encounter problems. Then, the problem reporter can focus on
 * providing a simple error message, leaving the donkey work of creating a nice model problem to this component.
 *
 */
class DefaultModelProblemCollector implements ModelProblemCollector {

    private final ModelBuilderResult result;

         * direct dependencies from the request will be merged with the direct dependencies from the root dependency's
         * artifact descriptor, giving higher priority to the dependencies from the request.
         *
         * @param dependencies the direct dependencies, may be {@code null}
         * @return this request for chaining, never {@code null}
         */