* infrastructure.<br>
 * It features an <code>execute()</code> method, which triggers the Mojo's build-process behavior, and can throw
 * a MojoException if error conditions occur.<br>
 *
 * @since 4.0.0
 */
@Experimental
@FunctionalInterface
@Consumer
public interface Mojo {
    /**
     * Perform whatever build-process behavior this <code>Mojo</code> implements.<br>

  2005-04-08
  ---

Offline Mode Design

* UPDATE: 18-April-2005

  We cannot take the approach outlined below of detecting which remote
  repositories are "really" offline, since offline mode is more of a behavior,
  and this will lead to counter-intuitive results. A different feature may exist
  unimplemented, which is to detect when the network is down and provide better

                }
            }
        }

        return s;
    }

    /**
     * Removes the leading directory separator from the specified filesystem path (if any). For platform-independent
     * behavior, this method accepts both the forward slash and the backward slash as separator.
     *
     * @param path The filesystem path, may be <code>null</code>.

            buildContext.getReactorBuildStatus().halt();
        } else {
            logger.error("invalid reactor failure behavior " + rootSession.getReactorFailureBehavior());
            buildContext.getReactorBuildStatus().halt();
        }
    }

    public static void attachToThread(MavenProject currentProject) {

                || FAIL_NEVER.equals(failureBehavior)) {
            this.failureBehavior = failureBehavior;
        } else {
            throw new IllegalArgumentException("Invalid failure behavior (must be one of: '" + FAIL_FAST + "', '"
                    + FAIL_AT_END + "', '" + FAIL_NEVER + "').");
        }
    }

    public String getFailureBehavior() {
        return failureBehavior;
    }

    /**
     * Artifact type name for a JAR file that can be placed either on the class-path or on the module-path.
     * The path (classes or modules) is chosen by the plugin, possibly using heuristic rules.
     * This is the behavior of Maven 3.
     */
    String JAR = "jar";

    /**
     * Artifact type name for a fat-JAR file that can be only on the class-path.

     *       class-path or on the module-path, but only one of those. The choice is up to the plugin,
     *       possibly using heuristic rules (Maven 3 behavior).</li>
     *   <li>If a {@link #patchModule(String)} is also set and the main JAR file is placed on the module-path,
     *       then the test dependency will be placed on the Java {@code --patch-module} option instead of the

import static org.junit.jupiter.api.Assertions.assertNotNull;
import static org.junit.jupiter.api.Assertions.assertTrue;

/**
 * Verifies scope inheritance of direct and transitive dependencies.
 *
 * Should show three behaviors:
 *
 * 1. dependencyManagement should override the scope of transitive dependencies.
 * 2. Direct dependencies should override the scope of dependencyManagement.

<pre>assertThat(cheese, is(smelly))</pre> * instead of: * <pre>assertThat(cheese, is(equalTo(smelly)))</pre> */ public static <T> org.hamcrest.Matcher<T> is(T value) { return org.hamcrest.core.Is.<T>is(value); } /** * Decorates another Matcher, retaining its behaviour, but allowing tests * to be slightly more expressive. * <p/> * For example: * <pre>assertThat(cheese, is(equalTo(smelly)))</pre> * instead of: * <pre>assertThat(cheese, equalTo(smelly))</pre> */ public static <T> org.hamcrest.Matcher<T> is(org.hamcrest.Matcher<T>...

        if ((makeBehavior != null && !makeBehavior.isEmpty()) && !makeUpstream && !makeDownstream) {
            throw new MavenExecutionException("Invalid reactor make behavior: " + makeBehavior, request.getPom());
        }

        if (makeUpstream || makeDownstream) {
            Set<MavenProject> projectsSet = new HashSet<>(projects);