Then I imported the project 1 dependency into project 2 and it gives following error. Seeking for a solution for this. org.spockframework.util.IncompatibleGroovyVersionException: The Spock JUnit runner cannot execute because Spock 1.1.0-groovy-2.4 is not compatible with Groovy 3.0.17.
Well, as the error says.
Where you get this error you have Groovy 3 with a Spock version that is for Groovy 2.4 and this is not compatible.
If the message is a red herring, you need to provide more details, optimally a build --scan.
Its failing when tests are executed. The error is org.spockframework.util.IncompatibleGroovyVersionException at VersionChecker.java:22.
Can’t we create a jar file without groovy dependencies? I want to add my project 1 dependency into project 2 without changing any groovy or other dependencies in project 2.
Can you provide an MCVE?
Having Spock as test framework in 2 should not at all influence 1 even with a dependency on 2.
So it is most probably something you configured. somehow.
But it is impossible to guess where the problem is, from the information you provided.
I don’t know where that detached configuration is from, but 3.0.17 is ok in 1, isn’t it?
The question is, why Spock 1.1.0-groovy-2.4 ends up in the test compile classpath of 1.
In project 1, it has added groovy libraries like this(library root). Also when I try to upgrade groovy 3.0.17 to 3.0.19 it gives me Module [groovy-datetime is loaded in version 3.0.17 and you are trying to load version 3.0.19 error. Seems like gradle 8.4 has groovy 3.0.17 inbuild and it doesn’t allow me to change groovy version into a different version as it already imported some modules from groovy 3.0.17.
Whatever Gradle has built-in (yes it is 3.0.17) should be irrelevant unless you build a Gradle plugin.
The normal production classpath or also the test classpath are unaffected by that unless you explicitly say you want that shipped version.
But again, you said your problem is that Spock 1.1-groovy-2.4 is in the test compile classpath and that is of course not compatible to Groovy 3 and that Groovy 3 is indeed what should be present in 1.
Anyway, I don’t think I can give any more meaningful advice as you neither provided the requested MCVE, nor the build scan, and from the little and contradictory information you gave it is impossible for me to come up with any suggestion.