* <p>
     * Shortcut for {@code getService(VersionResolver.class).resolve(...)}
     *
     * @param artifact the artifact for which to resolve the version
     * @return resolved version of the given artifact
     * @throws org.apache.maven.api.services.VersionResolverException if the resolution failed
     *

          <version>1.0.0/1.1.0</version>
          <type>String</type>
          <description>
            Flags this Mojo as requiring the dependencies in the specified class path to be resolved before it can
            execute: {@code compile}, {@code runtime}, {@code test},
            {@code compile+runtime} (since Maven 3.0) or {@code runtime+system} (since Maven 3.0)
          </description>
        </field>

    <configuration>
      <![CDATA[
<dependencies>
  ...
</dependencies>
    ]]></configuration>
    <description>
      <![CDATA[
      This is a set of Artifact instances resolved from the set of dependencies for
      the current project.

      NOTE: This will likely contain much more than the direct dependencies of the
      current POM, since Maven uses transitive, or chained, dependency resolution.

     * </p>
     * <p>
     * This method is the foundation for {@link SourceRoot#targetPath(Project)} path resolution.
     * When a {@link SourceRoot} has a relative {@code targetPath}, it is resolved against the
     * output directory returned by this method for the source root's scope. This ensures that:
     * </p>
     * <ul>

         * repository never uses timestamps in the filename of a snapshot artifact. The discrepancy gets notable when a
         * remotely resolved snapshot artifact gets passed into pathOf(). So producing a proper local artifact path
         * using DefaultRepositoryLayout requires us to enforce usage of the artifact's base version. This

            try {
                if (file.getName().equals("package-info.java")) {
                    if (canonicalPackageInfos.contains(file.getAbsoluteFile())) {
                        // The file collection may be resolved several times, e.g. for fingerprinting and for actual javadoc invocation.
                        // The method should be idempotent, so we record all package-info.java files we ever allowed and allow them afterward.

  /*
 *
 * h2. Concerns for the plugin manager
 *
 * h3. resolving the dependencies of a plugin - these could be resolved remotely at runtime or, -
 * they could be resolved from a local repository - I think we need a simple dependency model here
 * that is more mercury related and not Maven related i.e. no POMs - workspace resolver - we need

```console
$ <font color="#4E9A06">fastapi</font> dev <u style="text-decoration-style:single">main.py</u>
<font color="#3465A4">INFO    </font> Using path <font color="#3465A4">main.py</font>
<font color="#3465A4">INFO    </font> Resolved absolute path <font color="#75507B">/home/user/code/awesomeapp/</font><font color="#AD7FA8">main.py</font>

```console
$ <font color="#4E9A06">fastapi</font> dev <u style="text-decoration-style:single">main.py</u>
<font color="#3465A4">INFO    </font> Using path <font color="#3465A4">main.py</font>
<font color="#3465A4">INFO    </font> Resolved absolute path <font color="#75507B">/home/user/code/awesomeapp/</font><font color="#AD7FA8">main.py</font>

     */
    String JAR = "jar";

    /**
     * Artifact type name for a fat-JAR file that can be only on the class path.
     * The fat-JAR is a self-contained JAR and its transitive dependencies will not be resolved, if any.
     * This type is new in Maven 4.
     */
    String FATJAR = "fatjar";

    /**
     * Artifact type name for a JAR file to unconditionally place on the class path.