Could not parse Ivy file ... key can't be empty?

I’m exploring converting a Maven build to Gradle. After removing my .gradle/ entirely and starting a clean build I consistently get this kind of error:

Could not parse Ivy file … key can’t be empty

Sample output in linked pastebin, any advice appreciated (I get similar errors with Gradle 1.9, 2.0 and 2.1).

At a glance I can’t see what’s going wrong. Please provide the full stack trace of the exception: you can get this by executing Gradle with ‘–stacktrace’.

–stacktrace output:

I doubt this is related, but I am building with GRADLE_OPTS of -D -noverify (this is a groovy project)

I don’t think your GRADLE_OPTS are valid: you are providing an empty system property definition with ‘-D’, in addition to ‘-noverify’.

Gradle is loading all system properties into a Map in order to use these for property replacement when parsing the ivy file. Your empty ‘-D’ option would explain why the code is failing:

Caused by: java.lang.IllegalArgumentException: key can't be empty
        at java.lang.System.checkKey(
        at java.lang.System.getProperty(
        at org.gradle.api.internal.artifacts.ivyservice.ivyresolve.parser.IvyXmlModuleDescriptorParser.populateProperties(

Thanks, I thought that I might not have had the verify not quite right to begin with, however I think that gradle produces a very misleading error message. For example, my build fails with verification errors (apparently the stricter verifier dislikes some groovy code) – the failure manifesting as being unable to parse ivy.xml.

I think gradle can – and should – do a better job of reporting this error, it looked like a dependency resolution issue. For example: gradle build – with the incorrect gradle_opts, the build fails with what appears to be issues parsing ivy files that it generates.

I found this counter-intuitive, especially because simpler modules of this project build just fine with or without the incorrect GRADLE_OPTS, this led me to mistakenly continue with invalid opts since apparently only builds with more complex dependencies triggered this behavior (which is not what I would have expected)!