apache/maven · error · VersionResolverException

Unable to resolve version

Error message

Unable to resolve version

What it means

DefaultVersionResolver wraps the resolver's VersionResolutionException in VersionResolverException("Unable to resolve version"). This path resolves meta-versions — RELEASE, LATEST, and snapshot variants — from maven-metadata.xml in the local and remote repositories; it fails when that metadata is missing, unreadable, or does not contain a usable entry for the artifact.

Source

Thrown at impl/maven-impl/src/main/java/org/apache/maven/impl/DefaultVersionResolver.java:101

                @Override
                public Version getVersion() {
                    return session.parseVersion(res.getVersion());
                }

                @Override
                public Optional<Repository> getRepository() {
                    if (res.getRepository() instanceof org.eclipse.aether.repository.LocalRepository localRepository) {
                        return Optional.of(new DefaultLocalRepository(localRepository));
                    } else if (res.getRepository()
                            instanceof org.eclipse.aether.repository.RemoteRepository remoteRepository) {
                        return Optional.of(new DefaultRemoteRepository(remoteRepository));
                    } else {
                        return Optional.empty();
                    }
                }
            };
        } catch (VersionResolutionException e) {
            throw new VersionResolverException("Unable to resolve version", e);
        } finally {
            RequestTraceHelper.exit(trace);
        }
    }
}

View on GitHub (pinned to e4093d4e12)

Solutions

  1. Pin an explicit version instead of RELEASE/LATEST — the supported and reproducible practice
  2. Delete the corrupted local metadata for that groupId/artifactId under ~/.m2/repository and retry so it is re-fetched
  3. Confirm the remote repository actually publishes maven-metadata.xml for the artifact and that mirrors/proxies pass it through

Example fix

<!-- before -->
<dependency>
  <groupId>com.acme</groupId>
  <artifactId>api</artifactId>
  <version>RELEASE</version>
</dependency>

<!-- after -->
<dependency>
  <groupId>com.acme</groupId>
  <artifactId>api</artifactId>
  <version>1.4.2</version>
</dependency>
Defensive patterns

Strategy: try-catch

Validate before calling

// avoid meta-versions entirely; verify a concrete version exists in metadata before resolving
String version = "1.4.2";
if ("RELEASE".equals(version) || "LATEST".equals(version)) {
    throw new IllegalArgumentException("Meta-version '" + version + "' is not supported; pin an explicit version");
}

Try / catch

try {
    VersionResult r = versionResolver.resolve(session, request);
} catch (VersionResolverException e) {
    if (e.getCause() instanceof org.eclipse.aether.resolution.VersionResolutionException vr) {
        // metadata missing/corrupt: purge local copy and retry once with a pinned version
        purgeLocalMetadata(request.artifact());
        return versionResolver.resolve(session, withPinnedVersion(request, "1.4.2"));
    }
    throw e;
}

Prevention

When it happens

Trigger: versionResolver.resolve(session, request) for a dependency versioned 'RELEASE' or 'LATEST' when no repository (including the local cache) can serve maven-metadata.xml for the artifact; resolving an unresolvable SNAPSHOT whose metadata is absent or corrupted.

Common situations: Poms still using RELEASE/LATEST (deprecated since Maven 3 and rejected by many builds); interrupted downloads leaving truncated metadata in ~/.m2/repository; a remote repository that does not generate metadata; relocated artifacts behind mirrors.

Related errors


AI-assisted analysis of apache/maven@e4093d4e12 (2026-08-21). Data as JSON: /api/errors/63ed34775d850a25. Report an issue: GitHub.