>From a user and consultant perspective, I think dropping the Micronaut
support is the right call, though I say it with a heavy heart.

My client does not know about this discussion yet, but I am pretty sure
they will understand the reality of the situation. While they will not be
thrilled to see it go (we will particularly miss the Micronaut HTTP
Client), we have already spent a significant amount of time trying to get
the integration to work smoothly in our own environments, and the
bean-configuration with external-config continuously fail to work.

Seeing the breakdown of the dependency conflicts, the Java 21 vs. 25
divergence, and the resulting CVE risks makes it clear that fighting this
uphill battle is unsustainable for the core team. We cannot sacrifice the
security and stability of the framework for a high-maintenance feature with
low adoption.

Regarding the timeline, I agree with James's approach of releasing it as-is
in 8.0.0 to give remaining users a transition runway, but effectively
dropping support and freezing further updates unless an outside champion
steps up. Personally I do not have the clock-cycles to champion the Grail
Micronaut Plugin.

Thanks to James Fredley and James Daugherty for all the heavy lifting you
have done on this so far.

Den tirs. 16. jun. 2026 kl. 18.31 skrev Gianluca Sartori <
[email protected]>:

> I believe Grails 8 should decouple itself from Micronaut.
>
> Beyond all the points already raised, I don't see a strong architectural
> justification for including Micronaut in Grails. I genuinely appreciate the
> excellent work being done by the Micronaut team, but unless the intention
> is to make Grails a Micronaut-based framework—which feels like a discussion
> for another time and another reality—its integration introduces complexity
> with limited benefit.
>
> For that reason, I think dropping Micronaut support is the right decision.
>
> Gianluca Sartori
> --
> https://dueuno.com
>
>
> On Tue, 16 Jun 2026 at 15:06, 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
> >
>


-- 

Best regards
Søren Berg Glasius

Apache Groovy™ and Apache Grails® PMC
--- Press ESC once to quit - twice to save the changes.

Reply via email to