This topic came up again this week: while trying to test Grails with Groovy 6 (to ensure we can have a smooth upgrade when it releases). Micronaut releases don't currently have any such support and fail on Groovy 6. I'd like to start a vote thread on moving the Micronaut related functionality out of grails-core into its own repo so it doesn't continue to hinder Grails Version upgrades. Not just because of the Groovy version, but it's a real problem that we have to choose between libraries that Micronaut upgrades vs Spring upgrades. We've already had to make decisions related to CVEs that could leave applications vulnerable.
I'd like to propose we do this as of Grails 8 - so have it working for the initial Grails 8 release, and then rely on the community if support continues. If we can get support, then we can continue to support it in a laggard manner, but I don't want it to hold back Grails. On Wed, Jun 17, 2026 at 10:03 AM James Fredley <[email protected]> wrote: > > At the end of the day, someone that uses Micronaut in Grails will have to > step up to maintain it. It will be moving off grails-core into it's own > repo. James and I have put hundreds of hours into this and we are unsure > that more than 1 company is using it, given only one stated that it was > broken months after the Grails 7 release. The Spring Boot solution works > great for the declarative http client. > > On 2026/06/16 13:06:46 James Daugherty wrote: > > Hi Everyone, > > > > For the last 2 weekly meetings we have discussed the problems of > > integrating Micronaut & Spring. Both James Fredley & I have spent a > > significant amount of time ensuring Micronaut continues to work with > > Grails. While we have a solution for Grails 8, we don't think we can > > continue this support without a champion to help in this area. Here > > are the problems we've encountered: > > > > 1. Micronaut & Spring are updating dependencies at a different pace. > > This is really our core issue. For example, in Spring Boot 3.5.x > > Netty was updated to 4.1.x, while Micronaut jumped to 4.2.x. These > > version mismatches introduce hard incompatibilities which makes us > > choose which framework to prefer. Because Spring chose the lower > > version, we were forced to choose Netty 4.1.x, which meant that the > > Micronaut version had to be kept at a lower version. During 8.0's > > development, this was even more extreme due to the Micronaut 5.x > > development. > > > > 2. The downgrading of dependencies means CVEs in our dependent > > libraries often will exist and we will be unable to update. This is a > > huge blocker for us. We can't release insecure software. Without > > members on either the Micronaut or Spring teams, we can't really help > > resolve these issues. Micronaut has been helpful in updating > > libraries when we request, but we don't think it's reasonable to ask > > them to downgrade - we're not involved in their framework development. > > > > 3. Micronaut made the decision to jump all the way to Java 25 in > > Micronaut 5, even though 21 is still supported. Spring made the > > decision to support all the way back to 21. We had discussed going to > > 25, but we wanted to choose the minimum JVM version that would be > > supported for the life expectancy of Grails 8 (so we chose 21). This > > means that the micronaut portions of our build have to be built with > > Java 25, while the rest is built with Java 21. This is another huge > > issue for us because the ASF Security team requires reproducible > > builds. Which means a significant amount of work had to go into our > > verification process to support this divergence. > > > > 4. We have not seen significant contributions to the Micronaut support > > in Grails. Only James Fredley & James Daugherty have been evolving > > it. Without a champion to help with these problems, we are spending > > too much of our time on Micronaut and not enough on other core > > priorities (i.e. Hibernate 7). > > > > 5. We believe there are a low number of users still using the > > Micronaut support and thus the effort to continue this support is > > higher than the reward. > > > > This email is meant to start a wider discussion: we want to move the > > micronaut support into a side repository. If we can find a champion > > to help maintain it, then we can keep publishing it separate from > > Grails. Otherwise, we will eventually archive that integration and > > abandon it. > > > > -James > >
