Spock 2.0(-M3) reduced number of provided Groovy dependencies. If you started to get various Groovy-related
ClassNotFoundException
s after migration and wonder why and what to do, read on.
Historical background
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 pom.xml
and build.gradle
files.
What even worse, having some projects use groovy.jar
plus some modules (e.g. groovy-json.jar
or 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-all
BOM.
Groovy dependencies in Spock 1.3
Spock 1.2 switched from groovy-all.jar
to 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
to just 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.sql.Sql
, 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-sql:3.0.X
, 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.