and can be asserted as desired.

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.

    /**
     * Moderate trust - it was deployed directly by a user.
     */
    public static final ArtifactStatus DEPLOYED = new ArtifactStatus("deployed", 4);

    /**
     * Trusted, as it has had its data verified by hand.
     */
    public static final ArtifactStatus VERIFIED = new ArtifactStatus("verified", 5);

    private final int rank;

    private final String key;

    private static Map<String, ArtifactStatus> map;

        final List<String> stringList = Arrays.asList(
                "Thinkin", "of", "a", "master", "plan", "Cuz", "ain’t", "nuthin", "but", "sweat", "inside", "my",
                "hand");
        Iterator<String> lyrics = stringList.iterator();

        ExecutorService executor = Executors.newFixedThreadPool(10);
        CompletionService<ProjectSegment> service = new ExecutorCompletionService<>(executor);

https://opensource.org/licenses/BSD-3-Clause

Redistribution and use in source and binary forms, with or
without modification, are permitted provided that the following
conditions are met:

Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.

Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer

 * for a given artifact and builds a graph of them.
 * The dependencies collection mechanism will not download any artifacts,
 * and only the pom files will be downloaded.
 *
 * @since 4.0.0
 */
@Experimental
public interface DependencyCollector extends Service {

    /**
     * Collects the transitive dependencies and builds a dependency graph.

     * Gets the system properties to use for interpolation and profile activation. The system properties are collected
     * from the runtime environment like {@link System#getProperties()} and environment variables.
     *
     * @return The system properties, never {@code null}.
     */
    Properties getSystemProperties();

    /**
     * Sets the user properties to use for interpolation and profile activation. The user properties have been

 of models you may specify:

 all of the models that you specify are collected to produce a lineage and then the super model is place at
 the top of that lineage to provide default values.

 The super model is where we place all the values which we believe to be standard, values that can be shared and
 utilized across all your Maven projects.

+-----+
 m0 <- m1 <- m2
+-----+

 which is transformed into

        <executions>
          <execution>
            <id>the-one-and-only-id</id>
          </execution>
        </executions>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.its.plugins</groupId>
        <artifactId>maven-it-plugin-b</artifactId>
        <version>1.0-SNAPSHOT</version>
        <executions>
          <execution>
            <id>the-one-and-only-id</id>
          </execution>
        </executions>

 The jar file is executable and provides a little tool to display how Maven parses and compares versions:

+----+
$ java -jar maven-artifact-*.jar 3.2.4-alpha-1 3.2.4-SNAPSHOT 3.2.4.0
Display parameters as parsed by Maven (in canonical form) and comparison result:
1. 3.2.4-alpha-1 == 3.2.4.alpha.1
   3.2.4-alpha-1 < 3.2.4-SNAPSHOT

+ Submit a pull request to the repository in the Apache organization.
+ Update your JIRA ticket and include a link to the pull request in the ticket.

If you plan to contribute on a regular basis, please consider filing a [contributor license agreement][cla].

Making Trivial Changes
----------------------

For changes of a trivial nature to comments and documentation, it is not always