apache/maven · warning

e.getMessage()

Error message

e.getMessage()

What it means

LoggingRepositoryListener.metadataResolved fires after metadata resolution completes with an exception. MetadataNotFoundException (repository simply has no maven-metadata.xml) is logged at debug; every other failure is logged at warn with only e.getMessage() - the stack trace is attached only when debug is enabled (the separate logger.isDebugEnabled() branch). The message text is entirely the underlying exception's own description.

Source

Thrown at impl/maven-core/src/main/java/org/apache/maven/internal/aether/LoggingRepositoryListener.java:55

    @Override
    public void artifactInstalling(RepositoryEvent event) {
        logger.info("Installing {} to {}", event.getArtifact().getFile(), event.getFile());
    }

    @Override
    public void metadataInstalling(RepositoryEvent event) {
        logger.debug("Installing {} to {}", event.getMetadata(), event.getFile());
    }

    @Override
    public void metadataResolved(RepositoryEvent event) {
        Exception e = event.getException();
        if (e != null) {
            if (e instanceof MetadataNotFoundException) {
                logger.debug(e.getMessage());
            } else if (logger.isDebugEnabled()) {
                logger.warn(e.getMessage(), e);
            } else {
                logger.warn(e.getMessage());
            }
        }
    }

    @Override
    public void metadataInvalid(RepositoryEvent event) {
        Exception exception = event.getException();

        Object metadata;
        if (event.getMetadata().getFile() != null) {
            metadata = event.getMetadata().getFile();
        } else {
            metadata = event.getMetadata();
        }

        String errorType = " is invalid";

View on GitHub (pinned to e4093d4e12)

Solutions

1. Re-run with mvn -X (or -e) so the warn includes the full stack trace and the failing repository URL becomes visible
2. Check settings.xml mirrors/proxies for the affected repository and test the URL with curl
3. Delete the cached maven-metadata-*.xml files under ~/.m2/repository/<groupId>/<artifactId>/ and re-resolve with -U
4. Pin dependency/plugin versions instead of ranges, LATEST or RELEASE so stale metadata cannot break the build

// preflight the metadata endpoint before a metadata-heavy build (CI smoke check)
try (InputStream in = new URL(repoUrl + "/" + path + "/maven-metadata.xml").openStream()) {
    // reachable
} catch (FileNotFoundException notFound) {
    // fine: MetadataNotFoundException is only debug-logged
} catch (IOException e) {
    throw new IllegalStateException("Metadata endpoint unavailable: " + e.getMessage(), e);
}

try {
    versionRangeResult = versionRangeRequest -> resolve(...);
} catch (MetadataNotFoundException notFound) {
    // benign: repository has no metadata for the artifact
} catch (ArtifactResolutionException e) {
    // real transfer/parse failure: inspect cause, purge ~/.m2 metadata, retry with -U
}

When it happens

Trigger: Fetching maven-metadata.xml for a SNAPSHOT or version range fails with a transfer error (proxy 502, timeout), a checksum/validation failure, or an XML parse error on a cached/corrupted copy - anything other than a plain 404.

Common situations: Corporate mirrors that 500 on metadata requests; Artifactory/Nexus hiccups; corrupted metadata cached in ~/.m2/repository; offline mode with stale snapshot metadata.

Related errors

• {} could not be retrieved from repository: {} due to an erro
• Remote repository URL invalid
• Unsupported remote repository
• Unable to resolve version range
• Unable to resolve version

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