Die “Use Cases and Examples” von CycloneDX sind leider nur so mittel hilfreich für Gradle-Projekte, insbesondere solche ohne plugins DSL. Hier wie es trotzdem zu applyen ist:
Extra Properties Extensions sind für globale Properties; mir würde spontan bspw. einfallen, die eine Versionsnummer für meine drölf Spring-Dependencies so zu zentralisieren.
at com.acme.utils.SomeSpec.$spock_initializeFields(SomeSpec.groovy)
Caused by:groovy.lang.GroovyRuntimeException:Conflicting module versions.Module[groovy-all isloaded inversion2.4.9andyou are trying toload version2.4.10
at groovy.lang.GroovySystem.<clinit>(GroovySystem.java:36)
...1more
, bei Ausführen des Tests aus IntelliJ heraus; per Kommandozeile geht’s.
Internet sagt, man müsse die Dependency excluden (lokal oder global), um Sie dann in nur der gewünschten Version wieder zu includen, aber das führte bei mir bestenfalls nicht zum Erfolg, und schlimmstenfalls zu
Error:Cannot compile Groovy files: no Groovy library is defined for module ‘my-module_test’
Internet sagt weiterhin, man könne eine bestimme Version forcieren, aber das hat bei mir genau gar keine Auswirkungen.
Geholfen hat dann, das Setup aus compile und testCompile zu überprüfen: Ich hatte ein Modul mit Test-Sourcen als compile project, die Dependency org.codehaus.groovy:groovy-all:2.4.10 aber als test-compile eingebunden. Korrekt ist in dem Fall, das Modul als testCompile project einzubinden (oder alternativ die Dependency als compile, aber hier wäre das “falsch rum”).
Offenbar gilt von der Shell aus die höhere (oder die später deklarierte?) (transitive) Dependency, in IntelliJ aber die zuerst deklarierte.