Strange build failure while executing a complete multi-module build but building the failing module separately works fine

Old Forum Archive
1

I get the following failure in a multi-module project while executing ‘gradle build’:

:foo:bar:compileTestGroovy
startup failed:
Could not instantiate global transform class org.spockframework.compiler.SpockTransform specified at jar:file:/Users/jenkins/.gradle/caches/artifacts-23/filestore/org.spockframework/spock-core/0.7-groovy-2.0/jar/4de0b428de0c14b6eb6375d8174f71848cbfc1d7/spock-core-0.7-groovy-2.0.jar!/META-INF/services/org.codehaus.groovy.transform.ASTTransformation
because of exception org.spockframework.util.IncompatibleGroovyVersionException: The Spock compiler plugin cannot execute because Spock 0.7.0-groovy-2.0 is not compatible with Groovy 1.8.6. For more information, see http://versioninfo.spockframework.org
Spock location: file:/Users/jenkins/.gradle/caches/artifacts-23/filestore/org.spockframework/spock-core/0.7-groovy-2.0/jar/4de0b428de0c14b6eb6375d8174f71848cbfc1d7/spock-core-0.7-groovy-2.0.jar
Groovy location: file:/Users/jenkins/.gradle/wrapper/dists/gradle-1.5-bin/9si5v6u7tk37kj5dlsrdcm595/gradle-1.5/lib/groovy-all-1.8.6.jar
  1 error

If I change into /foo/bar and execute a ‘gradle build’ then everything works fine.

The method managedDependency used below is just a helper method that returns the same full dependency for a given group:artifact, i.e. always the same version. ‘org.codehaus.groovy:groovy’ (and other groovy artifacts) returns artifacts with version 2.1.3. I’m quite sure that this is method not related to the problem at hand.

The following stuff is contained in our configuration:

project.allprojects { project ->
 apply plugin: 'groovy'
    dependencies {
  groovy managedDependency('org.codehaus.groovy:groovy')
  groovy managedDependency('org.slf4j:slf4j-api')
  //@Slf4j
 }
    configurations.all {
  exclude group: 'commons-logging', module: 'commons-logging'
  exclude group: 'log4j', module: 'log4j'
  exclude group: 'org.codehaus.jackson', module: 'jackson-core-asl'
  exclude group: 'org.codehaus.jackson', module: 'jackson-mapper-asl'
  exclude group: 'org.codehaus.groovy', module: 'groovy-all'
 }
}

We also define the following general test dependencies for all submodules:

testCompile managedDependency('org.codehaus.groovy:groovy')
 testCompile managedDependency('org.spockframework:spock-core'), { exclude group: 'junit', module: 'junit-dep' }

The module :foo:bar defines the following dependencies:

groovy managedDependency('org.codehaus.groovy:groovy')
 groovy managedDependency('org.codehaus.groovy:groovy-xml')
 groovy managedDependency('org.codehaus.groovy:groovy-json')
   testCompile managedDependency('org.codehaus.groovy:groovy')

The ‘org.codehaus.groovy:groovy’ dependency is added over and over again, multiple times, on three levels, because I tried to frantically find a solution for that build failure. It didn’t look that bad from the start but even in this state, the correct groovy dependency is not picked up.

If I execute ‘gradle dependencies’ for :foo:bar then it correctly shows the ‘org.codehaus.groovy:groovy’ dependency with the expected version and there is no sign of any groovy-all (and, yes, it is somehow using the gradle groovy-all in that failure. oO)

I think I’ve grown some grey hair in the meantime and am now at a complete loss about how to go on and find a solution.

Please help me - and let me know where I should send any of the rather huge debug logs. (Once failing a complete build after a clean, once the output of the working build of just the submodule.)

Unfortunately, I can’t post them publicly. It’s company stuff.

2

Check for something depending on ‘localGroovy()’.

3

Woah, that was indeed the solution… oO

Another project in the multi-module build was using ‘localGroovy()’ - but it was entirely unrelated, i.e. no connection via dependency, to the failing project.

Further, we commented out the failing project in the meantime and some other project failed instead.

This is pretty much side-effect galore and I’d consider this as my first Maven experience (random build failure for no apparent reason) with Gradle. Hope you find some fix for this issue. I was nearly going insane.

Thank you very much for your help, though. Really appreciated!

4

I knew it was ‘localGroovy()’ because of Spock’s excellent error message, but I have no idea why it had this effect.

I’d like to work with you to fully understand this if you’re up for it. If you are and would prefer to discuss privately, please contact me directly.