You can change/extend these stubs, and tests should not be breaking too much, since most tests
assert using expected values from the stubs. Normally, when you try to use data from the stubs that
have not been properly populated, you'll get a nullpointer in your test and you then have to
identify which stub creates that specific piece of data.

The most important stubs are:
LifecycleExecutionPlanCalculatorStub
ProjectDependencyGraphStub

import org.apache.maven.artifact.resolver.ResolutionNode;

/**
 * Resolves conflicting artifacts by always selecting the farthest declaration. Farthest is defined as the
 * declaration that has the most transitive steps away from the project being built.
 *
 * @since 3.0
 */
@Named("farthest")
@Singleton
@Deprecated
public class FarthestConflictResolver implements ConflictResolver {

  <artifactId>child</artifactId>
  <version>1.0-SNAPSHOT</version>

  <name>Maven Integration Test :: MNG-2174</name>
  <description>
    Verify that plugin dependencies defined by plugin management of a parent profile are not lost when the
    parent's main plugin management section is also present.
  </description>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.its.plugins</groupId>

 |
 |                 -gt /path/to/global/toolchains.xml
 |
 | The sections in this sample file are intended to give you a running start at
 | getting the most out of your Maven installation.
 |-->
<toolchains xmlns="http://maven.apache.org/TOOLCHAINS/1.1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

    private final Logger logger = LoggerFactory.getLogger(getClass());

    private final MessageBuilderFactory messageBuilderFactory;

    /**
     * Default ctor is used in IT and most probably some 3rd party code. For those cases, we do provide sane defaults
     * but given this is a component, injection should be used, replacing direct instantiation.
     *

     */
    boolean isIncludesDependencies();

    /**
     * Types of path (class-path, module-path, …) where the dependency can be placed.
     * For most deterministic builds, the array length should be 1. In such case,
     * the dependency will be unconditionally placed on the specified type of path
     * and no heuristic rule will be involved.
     *

    filesystem, it will continue to be available.

  The question remaining is: Which level of offline mode will we support? It
  seems reasonable to assume that users will be able to tell when localhost is
  not active (in most cases, localhost should be available, even if the rest of
  the network is not). Therefore, let's concentrate on the state where no
  network <beyond localhost> exists, and leave the more extreme state to users

            // Just returning an Integer with the index here is faster, but requires a lot of if/then/else to check for
            // -1
            //  or QUALIFIERS.size and then resort to lexical ordering. Most comparisons are decided by the first
            // character,
            // so this is still fast. If more characters are needed then it requires a lexical sort anyway.

  <description>Test inheritance of UNC paths</description>

  <modules>
    <module>child</module>
  </modules>

  <distributionManagement>
    <site>
      <id>site</id>
      <url>file:////host/site</url>
    </site>
  </distributionManagement>

        <configuration>
          <address>******@****.***</address>
        </configuration>
      </notifier>
      <notifier>
        <type>irc</type>
        <configuration>
          <host>irc.codehaus.org</host>
          <port>6667</port>
          <channel>#plexus</channel>
        </configuration>
      </notifier>
    </notifiers>
  </ciManagement>
  <inceptionYear>2001</inceptionYear>
  <mailingLists>