* second invocation, so implementors have made various choices, including:
 *
 * <ul>
 *   <li>returning the same iterator again
 *   <li>throwing an exception of some kind
 *   <li>or the usual, <i>robust</i> behavior, which all known {@link Collection} implementations
 *       have, of returning a new, independent iterator
 * </ul>
 *

import org.apache.maven.api.services.ModelProblem;

/**
 * There are various forms of results that are represented by this class:
 * <ol>
 * <li>success - in which case only the model field is set
 * <li>success with warnings - model field + non-error model problems
 * <li>error - no model, but diagnostics
 * <li>error - (partial) model and diagnostics
 * </ol>
 * Could encode these variants as subclasses, but kept in one for now
 *

 *
 * <ul>
 *   <li><b>Shallow immutability.</b> Elements can never be added, removed or replaced in this
 *       collection. This is a stronger guarantee than that of {@link
 *       Collections#unmodifiableCollection}, whose contents change whenever the wrapped collection
 *       is modified.
 *   <li><b>Null-hostility.</b> This collection will never contain a null element.

 * Benchmarks (as of December 2011) show that:
 *
 * <ul>
 *   <li>for an unnested {@code lock()} and {@code unlock()}, a cycle detecting lock takes 38ns as
 *       opposed to the 24ns taken by a plain lock.
 *   <li>for nested locking, the cost increases with the depth of the nesting:
 *       <ul>
 *         <li>2 levels: average of 64ns per lock()/unlock()
 *         <li>3 levels: average of 77ns per lock()/unlock()

     * <ul>
     * <li>{@code *} (since 2.0.5)= everything,</li>
     * <li>{@code external:*}  (since 2.0.9)= everything not on the localhost and not file based,</li>
     * <li>{@code external:http:*} (since 3.8.0)= any repository not on the localhost using HTTP,</li>
     * <li>{@code repo,repo1}  (since 2.0.9)= {@code repo} or {@code repo1},</li>

     * </p>
     * <ul>
     *   <li>If this type is {@link JavaPathType#MODULES}, then this method returns
     *       {@code "--module-path path1:path2"} on Unix or {@code "--module-path path1;path2"} on Windows.</li>
     *   <li>If this type was created by {@code JavaPathType.patchModule("foo.bar")}, then the method returns

     * <p><b>Algorithm:</b>
     * If the given path is a directory, then there is a choice:
     * </p>
     * <ul>
     *   <li><b>Package hierarchy:</b> if a {@code module-info.class} file is found at the root,
     *       then builds a singleton map with the module name declared in that descriptor.</li>
     *   <li><b>Module hierarchy:</b> if {@code module-info.class} files are found in sub-directories,

 * second invocation, so implementors have made various choices, including:
 *
 * <ul>
 *   <li>returning the same iterator again
 *   <li>throwing an exception of some kind
 *   <li>or the usual, <i>robust</i> behavior, which all known {@link Collection} implementations
 *       have, of returning a new, independent iterator
 * </ul>
 *

 *
 * <p>For instance, if <i>steps</i> is 5, one example sequence that will be tested is:
 *
 * <ol>
 *   <li>remove();
 *   <li>hasNext()
 *   <li>hasNext();
 *   <li>remove();
 *   <li>next();
 * </ol>
 *
 * <p>This particular order of operations may be unrealistic, and testing all 3^5 of them may be

  /**
   * Determines whether two possibly-null objects are equal. Returns:
   *
   * <ul>
   *   <li>{@code true} if {@code a} and {@code b} are both null.
   *   <li>{@code true} if {@code a} and {@code b} are both non-null and they are equal according to
   *       {@link Object#equals(Object)}.
   *   <li>{@code false} in all other situations.
   * </ul>
   *