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

 * map from keys to <i>nonempty</i> collections of values:
 *
 * <ul>
 *   <li>a → 1, 2
 *   <li>b → 3
 * </ul>
 *
 * ... or as a single "flattened" collection of key-value pairs:
 *
 * <ul>
 *   <li>a → 1
 *   <li>a → 2
 *   <li>b → 3
 * </ul>
 *
 * <p><b>Important:</b> although the first interpretation resembles how most multimaps are

 *
 * <ul>
 *   <li>An annotation named just "Suppress" might someday be treated by a non-Android tool as a
 *       suppression. This would follow the precedent of many of our annotation processors, which
 *       look for any annotation named, e.g., "GwtIncompatible," regardless of package.
 *   <li>An annotation named just "Suppress" might suggest to users that the test is suppressed

        </ul>
    </ul>
</ul>

<ul style="direction: rtl;">
    <li><div style="text-align: right;"><b>Uvicorn</b>:</div></li>
    <ul>
        <li><div style="text-align: right;">بہترین کارکردگی ہوگی، کیونکہ اس میں سرور کے علاوہ زیادہ اضافی کوڈ نہیں ہے۔</div></li>

     * <ul>
     *   <li>If it starts with either "pom." or "project.", the expression is evaluated against the model.</li>
     *   <li>If the value is null, get the value from the context.</li>
     *   <li>If the value is null, but the context contains the expression, don't replace the expression string
     *       with the value, and continue to find other expressions.</li>

     * <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>This tests:
 *
 * <ul>
 *   <li>comparing each object against itself returns true
 *   <li>comparing each object against null returns false
 *   <li>comparing each object against an instance of an incompatible class returns false
 *   <li>comparing each pair of objects within the same equality group returns true
 *   <li>comparing each pair of objects from different equality groups returns false
 *   <li>the hash codes of any two equal objects are equal

 *
 * <ul>
 *   <li>whether threads should be marked as {@linkplain Thread#setDaemon daemon} threads
 *   <li>a {@linkplain ThreadFactoryBuilder#setNameFormat naming format}
 *   <li>a {@linkplain Thread#setPriority thread priority}
 *   <li>an {@linkplain Thread#setUncaughtExceptionHandler uncaught exception handler}
 *   <li>a {@linkplain ThreadFactory#newThread backing thread factory}
 * </ul>
 *

import org.apache.maven.execution.MavenSession;

/**
 * Component for use by the <code>maven-toolchains-plugin</code> only.
 * It provides API: <ol>
 * <li>to retrieve every toolchains available in user settings,</li>
 * <li>to store chosen toolchain into build context for later use by toolchain-aware plugins.</li>
 * </ol>
 *
 * @since 2.0.9
 * @see ToolchainManager#getToolchainFromBuildContext(String, MavenSession)
 */

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