Spock 2.0(-M3) reduced number of provided Groovy dependencies. If you started to get various Groovy-related
ClassNotFoundExceptions after migration and wonder why and what to do, read on.
Originally Groovy was just one
jar to rule them all. However, in process of time, that jar became bigger and bigger. Groovy 2 was the first version promoting the usage of (several at that time) Groovy modules, as a supplemental to
groovy.jar. However the adoption of that approach was slowly and
groovy-all remained prevalent in
What even worse, having some projects use
groovy.jar plus some modules (e.g.
groovy-xml.jar) while some other preferring good old
groovy-all.jar could lead to version clashes as for Maven or Gradle those were independent packages. To avoid that it was quite common to see the defensive Groovy exclusions:
and declare all required Groovy dependencies on their own.
Groovy 2.5 switched to the model of Maven’s BOM (Bill Of Materials) where
groovy-all isn’t a binary jar itself, but rather has the official Groovy modules as dependencies. Thanks to that, Maven and Gradle have easier to keep the versioning of the particular modules consistent. This holds for Groovy 3 which still provides the
Groovy dependencies in Spock 1.3
Spock 1.2 switched from
groovy.jar + modules. Unfortunately due to historical reasons it was a lot of modules:
testRuntimeClasspath - Runtime classpath of source set 'test'. +--- org.spockframework:spock-core:2.0-M2-groovy-3.0 | +--- org.codehaus.groovy:groovy:3.0.0 | +--- org.codehaus.groovy:groovy-json:3.0.0 | | \--- org.codehaus.groovy:groovy:3.0.0 | +--- org.codehaus.groovy:groovy-nio:3.0.0 | | \--- org.codehaus.groovy:groovy:3.0.0 | +--- org.codehaus.groovy:groovy-macro:3.0.0 | | \--- org.codehaus.groovy:groovy:3.0.0 | +--- org.codehaus.groovy:groovy-templates:3.0.0 | | +--- org.codehaus.groovy:groovy-xml:3.0.0 | | | \--- org.codehaus.groovy:groovy:3.0.0 | | \--- org.codehaus.groovy:groovy:3.0.0 | +--- org.codehaus.groovy:groovy-test:3.0.0 | | \--- org.codehaus.groovy:groovy:3.0.0 | +--- org.codehaus.groovy:groovy-sql:3.0.0 | | \--- org.codehaus.groovy:groovy:3.0.0 | +--- org.codehaus.groovy:groovy-xml:3.0.0 (*) | \--- org.junit.platform:junit-platform-engine:1.5.2 | ... ...
As a result the following was quite common:
However, it turned out that in fact all those extra modules are not needed internally for
spock-core and they were rather provided as a convenience for end users.
Groovy dependencies in Spock 2.0+
Starting with Spock 2.0-M3 the Groovy dependencies were simplified
groovy.jar. Thanks to that you safe some bandwidth on the initial build (what is well-timed ;-) ) and the CI builds without proper caching take slightly shorter.
testCompileClasspath - Compile classpath for source set 'test'. +--- org.spockframework:spock-core:2.0-M3-groovy-3.0 | +--- org.codehaus.groovy:groovy:3.0.4 | +--- org.junit.platform:junit-platform-engine:1.7.1-M1 | ... ...
As a downside, after the migration to Spock-2.0-M3+, in rare cases you might get
ClassNotFoundException: groovy.json.JsonSlurper or
ClassNotFoundException: groovy.util.XmlParser. That error suggest that you use those classes somewhere in your tests, but the corresponding dependency is not declared implicitly in your build configuration (and it’s not accidentally provided by
spock-core any longer). The quick fix is to add
org.codehaus.groovy:groovy-json:3.0.X or similar explicitly.
P.S. If you bumped into that topic during Spock 1.3 -> 2.0 migration, there is a dedicated migration guide article .Lead photo by Tumisu, published in Pixabay, Pixabay License.