Build failure caused by MetaDataParseException due to attempting to parse a .jar file as a Maven pom

Bugs
,
1

Gradle Version: 2.14.1
Operating System: Linux

I’m struggling with a strange problem that only seems to affect our CI builds, i.e. I’ve yet to see this happen locally (although that’s OS X). Builds are regularly failing due to an apparent attempt to parse a .jar file as a Maven pom:

Caused by: org.gradle.api.internal.artifacts.ivyservice.ivyresolve.parser.MetaDataParseException: Could not parse POM /opt/users/bamboo/.gradle/caches/modules-2/files-2.1/org.grails/grails-datastore-core/4.0.5.RELEASE/c3bc94ec87154c1f27ae50da68f86d0fd074f122/grails-datastore-core-4.0.5.RELEASE.jar
	at org.gradle.api.internal.artifacts.ivyservice.ivyresolve.parser.PomReader$1.transform(PomReader.java:100)
	at org.gradle.api.internal.artifacts.ivyservice.ivyresolve.parser.PomReader$1.transform(PomReader.java:95)
	at org.gradle.internal.resource.AbstractExternalResource.withContent(AbstractExternalResource.java:96)
	at org.gradle.api.internal.artifacts.ivyservice.ivyresolve.parser.PomReader.<init>(PomReader.java:95)
	at org.gradle.api.internal.artifacts.ivyservice.ivyresolve.parser.GradlePomModuleDescriptorParser.parseOtherPom(GradlePomModuleDescriptorParser.java:212)
	at org.gradle.api.internal.artifacts.ivyservice.ivyresolve.parser.GradlePomModuleDescriptorParser.doParsePom(GradlePomModuleDescriptorParser.java:87)
	at org.gradle.api.internal.artifacts.ivyservice.ivyresolve.parser.GradlePomModuleDescriptorParser.parseOtherPom(GradlePomModuleDescriptorParser.java:214)
	at org.gradle.api.internal.artifacts.ivyservice.ivyresolve.parser.GradlePomModuleDescriptorParser.doParsePom(GradlePomModuleDescriptorParser.java:87)
	at org.gradle.api.internal.artifacts.ivyservice.ivyresolve.parser.GradlePomModuleDescriptorParser.doParseDescriptor(GradlePomModuleDescriptorParser.java:70)
	at org.gradle.api.internal.artifacts.ivyservice.ivyresolve.parser.GradlePomModuleDescriptorParser.doParseDescriptor(GradlePomModuleDescriptorParser.java:46)
	at org.gradle.api.internal.artifacts.ivyservice.ivyresolve.parser.AbstractModuleDescriptorParser.parseDescriptor(AbstractModuleDescriptorParser.java:44)
	at org.gradle.api.internal.artifacts.ivyservice.ivyresolve.parser.AbstractModuleDescriptorParser.parseMetaData(AbstractModuleDescriptorParser.java:39)
	at org.gradle.api.internal.artifacts.repositories.resolver.MavenResolver.parseMetaDataFromResource(MavenResolver.java:199)
	at org.gradle.api.internal.artifacts.repositories.resolver.ExternalResourceResolver.parseMetaDataFromArtifact(ExternalResourceResolver.java:170)
	at org.gradle.api.internal.artifacts.repositories.resolver.ExternalResourceResolver.resolveStaticDependency(ExternalResourceResolver.java:143)
	at org.gradle.api.internal.artifacts.repositories.resolver.MavenResolver.doResolveComponentMetaData(MavenResolver.java:93)
	at org.gradle.api.internal.artifacts.repositories.resolver.ExternalResourceResolver$RemoteRepositoryAccess.resolveComponentMetaData(ExternalResourceResolver.java:409)
	at org.gradle.api.internal.artifacts.ivyservice.ivyresolve.CacheLockReleasingModuleComponentsRepository$LockReleasingRepositoryAccess$2.run(CacheLockReleasingModuleComponentsRepository.java:71)
	at org.gradle.internal.Factories$1.create(Factories.java:22)
	at org.gradle.cache.internal.DefaultCacheAccess.longRunningOperation(DefaultCacheAccess.java:242)
	at org.gradle.cache.internal.DefaultCacheAccess.longRunningOperation(DefaultCacheAccess.java:313)
	at org.gradle.cache.internal.DefaultPersistentDirectoryStore.longRunningOperation(DefaultPersistentDirectoryStore.java:114)
	at org.gradle.cache.internal.DefaultCacheFactory$ReferenceTrackingCache.longRunningOperation(DefaultCacheFactory.java:179)
	at org.gradle.api.internal.artifacts.ivyservice.DefaultCacheLockingManager.longRunningOperation(DefaultCacheLockingManager.java:56)
	at org.gradle.api.internal.artifacts.ivyservice.ivyresolve.CacheLockReleasingModuleComponentsRepository$LockReleasingRepositoryAccess.resolveComponentMetaData(CacheLockReleasingModuleComponentsRepository.java:69)
	at org.gradle.api.internal.artifacts.ivyservice.ivyresolve.CachingModuleComponentRepository$ResolveAndCacheRepositoryAccess.resolveComponentMetaData(CachingModuleComponentRepository.java:297)
	at org.gradle.api.internal.artifacts.ivyservice.ivyresolve.BaseModuleComponentRepositoryAccess.resolveComponentMetaData(BaseModuleComponentRepositoryAccess.java:42)
	at org.gradle.api.internal.artifacts.ivyservice.ivyresolve.memcache.InMemoryCachedModuleComponentRepository$CachedAccess.resolveComponentMetaData(InMemoryCachedModuleComponentRepository.java:75)
	at org.gradle.api.internal.artifacts.ivyservice.ivyresolve.ErrorHandlingModuleComponentRepository$ErrorHandlingModuleComponentRepositoryAccess.resolveComponentMetaData(ErrorHandlingModuleComponentRepository.java:89)
	... 197 more
Caused by: org.xml.sax.SAXParseException; systemId: file:/opt/users/bamboo/.gradle/caches/modules-2/files-2.1/org.grails/grails-datastore-core/4.0.5.RELEASE/c3bc94ec87154c1f27ae50da68f86d0fd074f122/grails-datastore-core-4.0.5.umnNumber: 1; Content is not allowed in prolog.
	at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
	at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source)
	at org.gradle.api.internal.artifacts.ivyservice.ivyresolve.parser.PomReader.parseToDom(PomReader.java:208)
	at org.gradle.api.internal.artifacts.ivyservice.ivyresolve.parser.PomReader$1.transform(PomReader.java:98)
	... 225 more

I’ve seen this both on 2.11 and on 2.14.1. Bizarrely, the problem also appears to be intermittent. Re-running a build or triggering a new build sometimes “fixes” the problem, although that appears to be less likely following the upgrade to 2.14.1. Here’s a log from a failed CI build and here’s the OSS project that’s being built.

2

Thank you for reporting. I looks like we had the same issue on our own CI servers once. We captured this as GRADLE-3458.

Do you sometimes clean your Gradle caches on your CI servers? After cleaning the Gradle cache on the affected machine the problem did not happen for us any more. How often does this happen to you?

3

Do you sometimes clean your Gradle caches on your CI servers?

Not as a matter of course, AFAIK.

How often does this happen to you?

It got to the stage yesterday where every build was failing with one weird error or another. Either the problem described here or a completely unexpected compilation error were the two most common. The compilation errors looks a lot like another symptom of GRADLE-3015, albeit for the “main” class path rather than the buildscript class path.

Running the same build again without making any changes whatsoever would produce a different failure. For the time being, the logs are available here if you are interested.

I threw in the towel this morning and updated the CI build’s configuration to delete Gradle’s cache prior to running the Gradle build. It passed for the first time in about 15 builds. This could be coincidence, but it certainly looks as if the cache was broken somehow and was the cause of all the weirdness.

I’m rather disheartened to see that GRADLE-3015 has been open for over two years and, after the initial forum discussion, has been ignored. There can be few more fundamental jobs for a Java build tool than getting the class path right on a consistent basis.