apache/maven · error · ArtifactResolutionException

Unable to get dependency information: " + e.getMessage()

Error message

Unable to get dependency information: " + e.getMessage()

What it means

DefaultLegacyArtifactCollector (the Maven 2/3-legacy transitive dependency resolver) must enumerate available versions when a dependency is declared with a version range. It calls ArtifactMetadataSource.retrieveAvailableVersions(...) to fetch maven-metadata.xml from the configured remote repositories; if that retrieval throws ArtifactMetadataRetrievalException (network failure, missing metadata, authentication error), it is wrapped into ArtifactResolutionException prefixed with 'Unable to get dependency information', carrying the reset artifact, the remote repositories and the original cause.

Source

Thrown at compat/maven-compat/src/main/java/org/apache/maven/repository/legacy/resolver/DefaultLegacyArtifactCollector.java:305

                                // MNG-2123: if the previous node was not a range, then it wouldn't have any available
                                // versions. We just clobbered the selected version above. (why? I have no idea.)
                                // So since we are here and this is ranges we must go figure out the version (for a
                                // third time...)
                                if (resetArtifact.getVersion() == null && resetArtifact.getVersionRange() != null) {

                                    // go find the version. This is a total hack. See previous comment.
                                    List<ArtifactVersion> versions = resetArtifact.getAvailableVersions();
                                    if (versions == null) {
                                        try {
                                            MetadataResolutionRequest metadataRequest =
                                                    new DefaultMetadataResolutionRequest(request);

                                            metadataRequest.setArtifact(resetArtifact);
                                            versions = source.retrieveAvailableVersions(metadataRequest);
                                            resetArtifact.setAvailableVersions(versions);
                                        } catch (ArtifactMetadataRetrievalException e) {
                                            resetArtifact.setDependencyTrail(node.getDependencyTrail());
                                            throw new ArtifactResolutionException(
                                                    "Unable to get dependency information: " + e.getMessage(),
                                                    resetArtifact,
                                                    request.getRemoteRepositories(),
                                                    e);
                                        }
                                    }
                                    // end hack

                                    // MNG-2861: match version can return null
                                    ArtifactVersion selectedVersion = resetArtifact
                                            .getVersionRange()
                                            .matchVersion(resetArtifact.getAvailableVersions());

                                    if (selectedVersion != null) {
                                        resetArtifact.selectVersion(selectedVersion.toString());
                                    } else {
                                        throw new OverConstrainedVersionException(
                                                "Unable to find a version in " + resetArtifact.getAvailableVersions()

View on GitHub (pinned to e4093d4e12)

Solutions

Check the wrapped cause (getCause()) to see the real retrieval failure — unauthorized, not found, or connection refused — and fix settings.xml credentials/mirror configuration accordingly
If running with -o or --legacy-local-repository, drop the flag or pre-warm the local cache with one online build
Refresh stale metadata with mvn -U to force re-fetch of maven-metadata.xml
Replace the version range with a concrete pinned version so no metadata enumeration is required

Example fix

<!-- before -->
<dependency>
  <groupId>com.example</groupId>
  <artifactId>lib</artifactId>
  <version>[1.0,2.0)</version>
</dependency>

<!-- after: pin an exact version to avoid remote metadata enumeration -->
<dependency>
  <groupId>com.example</groupId>
  <artifactId>lib</artifactId>
  <version>1.4.2</version>
</dependency>

Defensive patterns

Strategy: try-catch

Validate before calling

// Before resolving a ranged dependency, verify its metadata is reachable
try {
    List<ArtifactVersion> versions = metadataSource.retrieveAvailableVersions(
            new DefaultMetadataResolutionRequest(request).setArtifact(artifact));
    if (versions == null || versions.isEmpty()) {
        throw new IllegalStateException("No available versions for " + artifact.getId()
                + " — check repositories/offline mode before resolution");
    }
} catch (ArtifactMetadataRetrievalException e) {
    throw new IllegalStateException("Repository metadata unreachable for " + artifact.getId(), e);
}

Try / catch

try {
    artifactResolver.resolve(artifactRangeRequest);
} catch (ArtifactResolutionException e) {
    if (e.getMessage() != null && e.getMessage().startsWith("Unable to get dependency information")) {
        Throwable root = e.getCause(); // ArtifactMetadataRetrievalException with the real reason
        handleMetadataAccess(artifact, root); // e.g. prompt credentials, disable offline, skip module
    } else {
        throw e;
    }
}

Prevention

Prefer pinned dependency versions over ranges in CI builds to avoid remote metadata lookups
Warm the local repository with one full online build before enabling -o offline mode
Configure credentials and mirrors in settings.xml once per environment and assert them in a pre-build check

When it happens

Trigger: Resolving a dependency whose version is a range (e.g. [1.0,2.0)) in a build that uses the legacy resolver, while retrieveAvailableVersions fails: repository unreachable, 401/403 due to missing credentials, 404 for the metadata file, proxy interference, or mvn -o (offline) with the metadata not yet cached locally.

Common situations: CI builds run with -o/--offline or from within a restricted network; private repository credentials not configured in settings.xml; internal mirror that does not proxy the repository hosting the ranged dependency; ranged dependencies on artifacts whose maven-metadata.xml was never published.

Related errors

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