So, offline mode has several implications, some of which may not be
  altogether obvious:

  * Localhost may be unavailable. Therefore, even locally installed
    server processes which work by conversing over a port may fail.

  * Not all "remote" repositories will fail. Specifically, if the remote
    repo uses the file:// protocol, and it doesn't refer to a shared
    filesystem, it will continue to be available.

ing description, org.hamcrest.Matcher<T> matcher, java.lang.Object... values) { return org.hamcrest.core.DescribedAs.<T>describedAs(description, matcher, values); } /** * Creates a matcher for {@link Iterable}s that only matches when a single pass over the * examined {@link Iterable} yields items that are all matched by the specified * <code>itemMatcher</code>. * <p/> * For example: * <pre>assertThat(Arrays.asList("bar", "baz"), everyItem(startsWith("ba")))</pre> * * @param itemMatcher * the matcher...

     * The CLI feeds into an execution request so if a particular value is present in the execution request
     * then we will take that over the value coming from the user settings.
     */
    private static Settings adaptSettings(MavenExecutionRequest request) {
        File localRepo = request.getLocalRepositoryPath();

 *   {@code 1.0.RC2 < 1.0-RC3 < 1.0.1}; but prefer {@code 1.0.0-RC1} over {@code 1.0.0.RC1}, and more
 *   generally: {@code 1.0.X2 < 1.0-X3 < 1.0.1} for any string {@code X}; but prefer {@code 1.0.0-X1}
 *   over {@code 1.0.0.X1}.</li>
 * </ul>
 *
 * @see <a href="https://maven.apache.org/pom.html#version-order-specification">"Versioning" in the POM reference</a>
 */

     * version range and the specified version range.
     * <p>
     * Note: Precedence is given to the recommended version from this version range over the
     * recommended version from the specified version range.
     * </p>
     *
     * @param restriction the <code>VersionRange</code> that will be used to restrict this version
     *                    range.

            @since Maven 4.0.0-alpha-3
          </description>
          <type>String</type>
        </field>
        <field xdoc.separator="blank">
          <name>mojos</name>

      <groupId>org.apache.maven.wagon</groupId>
      <artifactId>wagon-file</artifactId>
    </dependency>

    <!-- CLI -->
    <dependency>
      <groupId>org.slf4j</groupId>
      <artifactId>jcl-over-slf4j</artifactId>
      <version>${slf4jVersion}</version>
      <scope>runtime</scope>
    </dependency>
    <dependency>
      <groupId>org.apache.maven.resolver</groupId>

conditions either of that version or of any later version published by
the Free Software Foundation. If the Program does not specify a version
number of this License, you may choose any version ever published by the
Free Software Foundation.

10. If you wish to incorporate parts of the Program into other free
programs whose distribution conditions are different, write to the

                    logger.warn("Could not persist build resumption data", e);
                }
            });
        }
    }

    /**
     * Nobody should ever use this method.
     *
     * @deprecated If you use this method and your code is not in Maven Core, stop doing this.
     */
    @Deprecated

* Along with this comes the testing strategies that make this work
* The repository model where plugins can be stored and cataloged
* Bridging this into an OSGi system: if this could be done then we can basically take over p2

TODO

- dealing with processing of input and adapting GAVs before searching i.e. plugin groups in Maven and default searching
- how to deal with resolution from different places like local/remote/workspace