* followed by <dfn>flattening</dfn> and <dfn>resolution</dfn>.
 * The version selection is done for each dependency during the collection phase.
 * The flatten phase keeps only a single version per ({@code groupId}, {@code artifactId}) pair.
 * The resolution phase actually downloads the dependencies (or artifacts) that have been computed.
 *
 * @since 4.0.0
 */
@Experimental

                && e.getCause().getCause() instanceof ArtifactNotFoundException;
    }

    private boolean isNonTransferablePom(Exception e) {
        if (e.getCause() instanceof ArtifactResolutionException) {
            return true;
        }
        return e.getCause() instanceof org.eclipse.aether.resolution.ArtifactResolutionException

                        "Unable to find field '" + resolution.getField() + "' annotated with @Resolution");
            }
            field.setAccessible(true);
            String pathScope = resolution.getPathScope();
            Object result = null;
            if (pathScope != null && !pathScope.isEmpty()) {
                // resolution

    /**
     * Gets the SIDs of members of a group.
     *
     * @param tc the CIFS context to use
     * @param authorityServerName the server to use for resolution
     * @param domsid the domain SID
     * @param rid the group RID
     * @param flags resolution flags
     * @return the SIDs of the group members
     * @throws CIFSException if there is an error retrieving group members
     */

import java.util.Date;
import java.util.List;
import java.util.Properties;

import org.apache.maven.model.Model;
import org.apache.maven.model.Profile;
import org.apache.maven.model.resolution.ModelResolver;
import org.apache.maven.model.resolution.WorkspaceModelResolver;

/**
 * Collects settings that control the building of effective models.
 *
 * @deprecated use {@code org.apache.maven.api.services.ModelBuilder} instead
 */

repository. During development in an IDE we would need layered resolution approach that would allow resolution from the workspace, then the local Maven repository and then from any number of remote Maven repositories. During development from the command line we would need a layered resolution approach that would allow resolution from the local Maven repository and then from any number of remote Maven repositories. In production the resolution for the dependencies could also be layered but would depend...

     */
    @Nonnull
    Collection<BuilderProblem> getProblems();

    /**
     * Gets the result of the dependency resolution for the project.
     *
     * @return the result of the dependency resolution for the project
     */
    @Nonnull
    Optional<DependencyResolverResult> getDependencyResolverResult();

     * repositories and their contents.
     *
     * @param session the session to use
     * @param artifactCoordinates t
     * @return the version range resolution result
     * @throws VersionResolverException if an errors occurs
     */
    @Nonnull
    default VersionRangeResolverResult resolve(
            @Nonnull Session session, @Nonnull ArtifactCoordinates artifactCoordinates)

 * project. This includes compile-time only, runtime, test time, and various other combinations.</p>
 *
 * <h3>Resolution</h3>
 *
 * <p><dfn>Version resolution</dfn> is the process of finding, for a given artifact, a list of
 * versions that match the input {@linkplain org.apache.maven.api.VersionConstraint version constraint}

            </Export-Package>
            <Import-Package>
              com.google.common.util.concurrent.internal,
              org.jspecify.annotations;resolution:=optional,
              javax.crypto.*;resolution:=optional,
              sun.misc.*;resolution:=optional
            </Import-Package>
            <Bundle-DocURL>https://github.com/google/guava/</Bundle-DocURL>
          </instructions>
        </configuration>