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
- Pin an explicit version instead of RELEASE/LATEST — the supported and reproducible practice
- Delete the corrupted local metadata for that groupId/artifactId under ~/.m2/repository and retry so it is re-fetched
- 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
- Never depend on RELEASE/LATEST; pin explicit versions (also required for reproducible builds)
- After interrupted builds, delete the affected maven-metadata-*.xml files under ~/.m2/repository
- Confirm remote repositories publish metadata for the artifacts you consume
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
- Unable to resolve version range
- Error updating group repository metadata
- Cannot read metadata from '{}': {}
- {} could not be retrieved from repository: {} due to an erro
- Error installing metadata: {}
AI-assisted analysis of apache/maven@e4093d4e12 (2026-08-21).
Data as JSON: /api/errors/63ed34775d850a25.
Report an issue: GitHub.