> > Furthermore... what is the actual story for the user for having Grails > on top of Micronaut in the first place if Grails does not plan to go > away from Spring to Micronaut? >
That was my question at the beginning of the new Grails community driven process, the reason was mostly due to the better HttpClient that Micronaur had at the time. Now we (finally) have a ton of them in Spring and Apache for any level of abstraction you need/prefer to make a service call. And BTW, my work has been very much inspired by the Grails & Micronaut developers and I am a fan of the people who brought Groovy & Grails to the universe. But the architect in me is kicking my balls every time he can for the decision of including Micronaut (which I love and appreciate) in Grails. Gianluca Sartori -- https://dueuno.com > > bye Jochen > > On 6/16/26 15:06, 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 > >
