Thanks for outlining the challenges with Micronaut so clearly. Rather than moving it to a side repository immediately, I propose a phased sunsetting strategy. I also think we should include Hibernate 5 (h5) in this exact same plan.
Here is my proposed path: Grails 8.0.x: Micronaut and h5 are kept in the build. It is uncomfortable but manageable. We accept patches only. Grails 8.1.x: They are kept in the codebase historically, but are strictly unmaintained. Grails 9.0.x: Micronaut and h5 are completely removed. This approach gives any remaining users a predictable runway while immediately reducing our maintenance burden so we can focus on core priorities like the Hibernate 7 migration. What does the team think Thanks, Walter > On Jun 16, 2026, at 8:06 AM, James Daugherty <[email protected]> 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
