/**
 * Specific problems during resolution that we want to account for:
 * <ul>
 *   <li>missing metadata</li>
 *   <li>version range violations</li>
 *   <li>version circular dependencies</li>
 *   <li>missing artifacts</li>
 *   <li>network/transfer errors</li>
 *   <li>file system errors: permissions</li>
 * </ul>
 *
 * TODO carlos: all these possible has*Exceptions and get*Exceptions methods make the clients too

     * <ul>
     * <li>{@code *} = everything,</li>
     * <li>{@code external:*} = everything not on the localhost and not file based,</li>
     * <li>{@code external:http:*} = any repository not on the localhost using HTTP,</li>
     * <li>{@code repo,repo1} = {@code repo} or {@code repo1},</li>
     * <li>{@code *,!repo1} = everything except {@code repo1}.</li>
     * </ul>
     *

/**
 * Provide a summary of the exception, containing:<ul>
 * <li>the exception itself,</li>
 * <li>useful end-user message,</li>
 * <li>useful reference to a solution, or set of solutions: this is usually a wiki page url in
 * <a href="http://cwiki.apache.org/confluence/display/MAVEN/">http://cwiki.apache.org/confluence/display/MAVEN/</a>,
 * </li>
 * <li>child exception summaries.</li>
 * </ul>
 */
public class ExceptionSummary {

     *     </ul>
     *   </li>
     *   <li>Otherwise (test output contains no module information), then:
     *     <ul>
     *       <li>If the main output is on the module-path, place the test output
     *           on a {@code --patch-module} option.</li>
     *       <li>Otherwise (main output on the class-path), place the test output on the class-path too.</li>
     *     </ul>
     *   </li>

     * Some spec examples are:
     * <ul>
     * <li><code>1.0</code> Version 1.0 as a recommended version</li>
     * <li><code>[1.0]</code> Version 1.0 explicitly only</li>
     * <li><code>[1.0,2.0)</code> Versions 1.0 (included) to 2.0 (not included)</li>
     * <li><code>[1.0,2.0]</code> Versions 1.0 to 2.0 (both included)</li>
     * <li><code>[1.5,)</code> Versions 1.5 and higher</li>

     * be able to accept <code>relative</code> parameter values that
     * <ul>
     * <li>use either / or \ file path separator,</li>
     * <li>have .. parent directory references,</li>
     * <li>point either at file or directory.</li>
     * </ul>
     *
     * @param relative is the path of the requested source relative to this source

     * <li>The parent uses aggregation and refers to the child via the modules section</li>
     * <li>The module path to the child is considered to
     * point at the POM rather than its base directory if the path ends with ".xml" (ignoring case)</li>
     * <li>The name of the child's base directory matches the artifact id of the child.</li>
     * </ul>

     * <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,

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>
     *   <li>Otherwise (test output contains no module information), then:
     *     <ul>
     *       <li>If the main output is on the module-path, place the test output
     *           on a {@code --patch-module} option.</li>
     *       <li>Otherwise (main output on the class-path), place the test output on the class-path too.</li>
     *     </ul>
     *   </li>