gradle/gradle · error · MetaDataParseException
Could not parse %s %s
Error message
Could not parse %s %s
What it means
AbstractModuleDescriptorParser.parseDescriptor wraps any non-MetaDataParseException thrown by a concrete parser (ivy.xml, POM-derived, or module-metadata parsers) into MetaDataParseException, formatted as 'Could not parse <typeName> <resource>' with the descriptor kind and the resource location, chaining the underlying exception. It marks the point where a downloaded/cached descriptor file turned out to be unparseable.
Source
Thrown at platforms/software/dependency-management/src/main/java/org/gradle/api/internal/artifacts/ivyservice/ivyresolve/parser/AbstractModuleDescriptorParser.java:54
}
@Override
public ParseResult<T> parseMetaData(DescriptorParseContext ivySettings, File descriptorFile) throws MetaDataParseException {
return parseMetaData(ivySettings, descriptorFile, false);
}
@Override
public ParseResult<T> parseMetaData(DescriptorParseContext ivySettings, LocallyAvailableExternalResource resource) throws MetaDataParseException {
return parseDescriptor(ivySettings, resource, false);
}
protected ParseResult<T> parseDescriptor(DescriptorParseContext ivySettings, LocallyAvailableExternalResource resource, boolean validate) throws MetaDataParseException {
try {
return doParseDescriptor(ivySettings, resource, validate);
} catch (MetaDataParseException e) {
throw e;
} catch (Exception e) {
throw new MetaDataParseException(getTypeName(), resource, e);
}
}
protected abstract String getTypeName();
protected abstract ParseResult<T> doParseDescriptor(DescriptorParseContext ivySettings, LocallyAvailableExternalResource resource, boolean validate) throws Exception;
}
View on GitHub (pinned to 534f27719b)
Solutions
- Open the resource path printed in the message - it usually shows an HTML error page or broken XML, telling you the real problem (auth, proxy, 404)
- Refresh the poisoned cache: ./gradlew --refresh-dependencies or delete the module's directory under ~/.gradle/caches/modules-2
- If the artifact itself is broken, pin an unaffected version, or exclude the dependency and replace it (resolutionStrategy.dependencySubstitution)
- Fix the repository URL or credentials so the repository returns real metadata
Example fix
# before
repositories { maven { url 'https://repo.example.com/libs' } } # returns 403 HTML page
./gradlew build # Could not parse ivy module descriptor ...
# after
repositories { maven { url 'https://repo.example.com/libs'; credentials { ... } } }
./gradlew build --refresh-dependencies Defensive patterns
Strategy: try-catch
Validate before calling
// Sanity-check a repository before relying on its metadata
repositories {
maven {
url 'https://repo.example.com/libs'
content { includeGroupByRegex 'org\\.example\\..*' }
}
}
// content filtering prevents grabbing HTML error pages from the wrong repo Try / catch
try {
configurations.compileClasspath.resolve()
} catch (org.gradle.api.internal.artifacts.ivyservice.ivyresolve.parser.MetaDataParseException e) {
def loc = e.message.substring(e.message.indexOf('file:') >= 0 ? e.message.indexOf('file:') : 0)
throw new GradleException("Unparseable descriptor at ${loc} - open it to check for an HTML error page or broken XML", e)
} Prevention
- Configure repository credentials and correct URLs so error pages are not served as descriptors
- Run --refresh-dependencies after network failures to evict truncated cached files
- Use content filters (includeGroup/IncludeGroupByRegex) to keep each dependency on its intended repository
- When a third-party descriptor is genuinely broken, pin a good version or substitute the module
When it happens
Trigger: A repository serves a 404/403 HTML page cached under the ivy.xml or pom name; truncated or half-written XML from an interrupted download; an ivy.xml using entities/features the parser rejects; module metadata with an unsupported format version.
Common situations: Misconfigured repository URLs (proxy error pages, Nexus/Artifactory auth pages) served instead of descriptors; flaky networks leaving corrupt cached files; SNAPSHOT metadata rewritten mid-download; third-party modules with hand-crafted ivy.xml.
Related errors
- Unable to load Maven meta-data from %s.
- Could not generate worker process bootstrap classes.
- Cannot load transformed entry {transformedPath.getAbsolutePa
- Unexpected marker file: {markerFile} in instrumented buildsc
- Failed to create receipt for instrumented classpath file '%s
AI-assisted analysis of gradle/gradle@534f27719b (2026-08-22).
Data as JSON: /api/errors/870ee2cb16e0cc81.
Report an issue: GitHub.