Upgrade to Groovy 5.0.0.
Comment From: snicoll
This is blocked until a compatible Spock release is available, see https://github.com/spockframework/spock/issues/2196
Comment From: snicoll
This is blocked again as REST Assured isn't compatible with Groovy 5.
Comment From: nicolasb29
Hi,
Why this PR was merged since there was a problem with RestAssured (since M3 and RC1) ? This is a big problem for developpers which are using this RestAssured.
Comment From: wilkinsona
These situations are always difficult but we decided that the last bad option was to pick up the latest Groovy major in Spring Boot's new major. We realise that REST Assured is incompatible with it. That's unfortunate but not sufficient reason to get "stuck" on Groovy 4. If you want to use Spring Boot 4 with REST Assured, you may have some success downgrading Groovy back to 4.x. Alternatively, Spring Boot 3.5.x will be supported for 12 months after the release of Boot 4.0 and continues to use Groovy 4 and provide some REST Assured integration.
Comment From: nicolasb29
I understand that you want to be on the latest major version of Groovy but it is sad that it was done after 3 milestones. For example we have around 1000 applications based on Spring boot and we are working since the first milestone to adapt them to upgrade them as soon as possible after the final release. It seems too that tools are not ready for Groovy 5 (on the page of intellij they said that the compatible syntax is Groovy 4, and Gradle 9 is also on Groovy 4).
You adid major update of dependencies on minor version of Spring boot (for example Jedis), it is not possible to wait for upgrading to Groovy 5?
Comment From: snicoll
I don't really understand what you mean. Groovy 5 was announced on August 24 and we've tried to upgrade on September 10. This wasn't possible due to Spock and RestAssured not having a compatible release.
We're reached out to both of them, trying to see if we could get something in time for our GA. We've missed M3 which is the first milestone where that could have happened, not 3. When we concluded we wouldn't get support in time, we took the decision that Andy already explained to you and upgraded in RC1. I believe we've done more than our fair share to reach a positive conclusion for everyone.
You adid major update of dependencies on minor version of Spring boot (for example Jedis), it is not possible to wait for upgrading to Groovy 5?
When did we upgrade to a major of Jedis in a minor of Spring Boot? If we did, I don't think that's an argument as we did that because we hadn't any other choice: it could be a CVE or another project requiring it that we had to update or this wasn't a "real major".
Comment From: wilkinsona
I understand that you want to be on the latest major version of Groovy but it is sad that it was done after 3 milestones.
Groovy 5.0.0 was released on 21 August, the same day as Spring Boot 4.0.0-M2. That means that the earliest possible release that Boot could have realistically included it was 4.0.0-M3. We delayed a long as we could to assess the situation with the broader ecosystem, with 4.0.0-RC1 being the latest at which we could make such a change.
and Gradle 9 is also on Groovy 4
The default version of Groovy in Spring Boot's dependency management will have no effect on the version of Groovy that Gradle uses to power its Groovy DSL.
You adid major update of dependencies on minor version of Spring boot (for example Jedis), it is not possible to wait for upgrading to Groovy 5?
New major versions are not all the same and they vary considerably in their scope and impact. The scope of the Jedis upgrade was narrow and its impact low both because of its narrow scope and because it was largely a drop-in replacement for the previous version.
A new Groovy major is more like a new Kotlin major in terms of backwards compatibility. We upgraded to Kotlin 2.x in Spring Boot 4.0, similar to how we upgraded to Groovy 3.x in Spring Boot 3.0.
We couldn't accept an argument that the Groovy 5.0 upgrade is too disruptive for Spring Boot 4.0 and then make the change in a 4.x minor release where upgrades should be less disruptive. The problem with REST Assured may have been addressed by then, but it could break someone else just as badly due to another dependency that they heavily rely upon.
The alternative to an upgrade in a 4.x minor would be to delay until Spring Boot 5. We don't have even a rough date for that and it's likely to be in a few years' time at the earliest. All-in-all, we realise that the Groovy 5 upgrade may cause some inconvenience but, given the alternatives, Spring Boot 4.0 is the right time for it to happen.
Thank you for tracking the 4.0 milestones and please do let us know how you get on with downgrading Groovy to 4.0.x. Spring Boot itself only touches Groovy directly for its Groovy Templates support. If you're not using that, a downgrade to 4.0 should be an option for you until a Groovy 5-compatible version of REST Assured is available. You may also want to consider helping the REST Assured project to ship such a version. The sole maintainer of the project accepts sponsorships, for example.
Comment From: nicolasb29
Thanks for your response. I worked on a PR for RestAssured since Friday. Hope that it will be approved.
Comment From: wilkinsona
That's great to see, @nicolasb29. Thanks very much for opening that PR.
Comment From: bezchmurny
Alternatively, Spring Boot 3.5.x will be supported for 12 months after the release of Boot 4.0 and continues to use Groovy 4 and provide some REST Assured integration.
Is that accurate?
According to https://spring.io/projects/generations#support OSS support for 3.5.x ends in June 2026.
Comment From: wilkinsona
Thanks for catching that. I was going by memory and should have double-checked. It's 6 months as shown on the support page.
Comment From: bezchmurny
Thanks for clarifying.
It seems to me that at the moment a dependency override of Groovy can be done as an interim measure. In my limited tests that seemed to work fine.