Grails 7 Scope - Remove Micronaut Context

[davydotcom]

The grails team have been discussing whether or not it is worth keeping the Micronaut Context as the Parent Context in Grails (since Grail 4.x). This has caused issues in development regarding configuration loading , among others. It also has led to preventions on usages of reloaders like the hotswap-agent (those may be resolvable however). The thought is to let Grails be based on spring and not mix the other framework in. That being said micronaut can still be used within the project in a more standalone manner.

[sdelamo]

Removing Micronaut Context as the parent context of the Spring Boot context means you would not longer be able to:

• Inject a Micronaut Bean in a Grails Controller/Service.
• Use a declarative Micronaut HTTP Client and injected into a Grails Controller/Service
• Use Micronaut Configuration Properties
• Use non-HTTP Micronaut modules (Redis, Kafka) in a Grails application.

[ysb33r]

Having read everything in this discussion up to 12 Sep, I am like @gsartori . I would have preferred Grails to have become Micronaut with a nice syntactic sugar on top. (Just like Grails currently is SpringBoot with syntactic sugar on top). I would have thought that the pathway for Spring Boot people then to have used the Micronaut Spring support to still use Spring with Grails.

Alas, I guess this is not to be,and I think in the use cases we have been using Grails in, we'll probably switch to using Micronaut + Views instead. It might a bit more work on the Views side for us, but so be it. The choice of the majority in this community should drive the decision.

[jamesfredley]

Technically it would have been a new framework to truly convert Grails from Spring Boot to Micronaut, maybe Mrails or Granaut. It is unlikely that the feature set would be the same. Spring Boot and Micronaut have an overlap in use cases, but are architecturally distinct and Grails has historically been a Servlet API based full stack web framework with Spring Boot as the foundation, at least since 3. Micronaut was also there, since 4, but nearly everything was foundationally coming from Spring, which is illustrated by the PR that removed Micronaut by default: #13685

micronaut-projects/micronaut-views#5 is a good example of the challenges.

https://github.com/orgs/grails/discussions/13517#discussioncomment-10628928 provides a solid path for users who want to continue using the Micronaut Parent Context features in Grails. It appears to cover the prior uses cases and possibly more.

Grails 7 will be on Spring 6.2 and Spring Boot 3.4 and will follow those releases very closely now that the OSS support cycle is shorter.

[codeconsole]

@ysb33r you would risk switching to a new framework that was created by the some of the people that created this framework with virtually no easy pathway to migrate away from this framework? What makes you think that won't happen again in the future? The focus of Grails going forward is rock solid stability.

Spring Framework has been around since 2002 and continues to evolve. Micronaut provides integration with Spring. If there are features you want to integrate from Micronaut, the capability still exists.

There was nothing taken out of Grails other than hooks into an old version of Micronaut. Now Grails is cleaner and leaner on a 100% modern stack. There is nothing you could have done previously that you can not do now. In fact, if anything, you are able to better utilize Micronaut and not be stuck depending on an old version of it.

[ysb33r]

@codeconsole In the current context that we have, we are left with three Grails apps. One of them does not even use GSPs, one does so fully and one half-baked. Most of our apps are now on Micronaut. We really wanted to share domain objects and some other logic that we write in Micronaut in our Grails projects. As it stands we could move two of those projects to Micronaut anyway. It leaves us with one, which we either have to rewrite as Grails 7 or move to MN Views.

As much as I have supported Grails over the years, in this context it is not making much sense.

[ppazos]

I can understand this might not make sense for some but it did for most. I guess you can't please all the people all the time.

[sbglasius]

If Micronaut was to be come a plugin, so it became an optional plugin, I would see that as a big plus.

[itexto]

My biggest issue with Micronaut in Grails is the fact thait's not clear WHY Micronaut is a worth addition for the framework (here is the link of the current user guide: https://docs.grails.org/6.2.0/guide/single.html ) on the main documentation.

This is the main problem: for the newbie (and I'm not a newbie, I'm a Grails user since the beginning and even wrote a bookt about it "Falando de Grails") it's not clear the bennefits of Micronaut. And I must confess, even for me is not clear.

One of the nicest features we could have was a faster startup of the application. And the fact is that even today we still don't have this.

[gsartori]

What is the business need?

@osscontributor My guess is to promote Micronaut. In marketing, if you have a room full with 100 people using X you can get into that room and tell them about Y. And if you tell them that Y gives value to X is more likely for them to accept Y. A kind of Cross-Selling, so to say, but to communicate, in this case.

The big elefant we have in our room is that, at the moment, Micronaut needs Grails more than Grails needs Micronaut. Grails became a use-case for Micronaut.

But since I am the latest one joining the crew and the first of the ignorants, I won't argument more on this :) If the price to have Grails 7 is to keep Micronaut, so be it.

I come in peace :)

[jeffscottbrown]

"My guess is to promote Micronaut." - That isn't why we did it. It really wasn't a business decision. It was a technical decision. From my perspective we really did choose to fund the development of that integration to enable folks who wanted the Grails ecosystem and still wanted to be able to leverage powerful capabilities offered by Micronaut.

"The big elefant (sic) we have in our room is that, at the moment, Micronaut needs Grails more than Grails needs Micronaut." - I don't see it that way but that is an interesting perspective.

All good info. Thank you!

[gsartori]

@osscontributor my thoughts depend in large part on the reluctancy to remove Micronaut.

Anyway, the reason why you've added Micronaut, to my eyes, looks compatible with an implementation as a "Micronaut Grails Plugin" instead of a core component.

So, why can't we give Mirconaut Grails Plugin a chance?

[jeffscottbrown]

"So, why can't we give Mirconaut Grails Plugin a chance?" - I don't know. We probably could.

All the input really is appreciated. My comments were just to help clarify why we integrated the technologies and address some of the comments above that relay a different perspective than I think we had when we introduced the integration. It really wasn't a business decision to promote Micronaut or trying to enable the Grails community to use Micronaut momentum. The integration was prioritized because of technical capabilities. Looking back at that decision some folks will weigh the tradeoffs differently and not everyone will agree on the best thing, but at least understanding what our motives were for introducing that integration may be helpful. For moving forward, I am not making an argument in either direction.

Thank you for all of the input!

[sdelamo]

If anyone willing to contribute a a PR to remove Micronaut from Grails or make Micronaut Grails Plugin, please contribute it. I personally have not appetite for either.

I am not sure a Micronaut Grails Plugin is even possible.

[sdelamo]

There is a work-in-progress PR currently updating to Micronaut 4.5.3 #13545

[rlconst]

@sdelamo is micronaut 4.x viable on gradle 7.x?

[amacleay-cohere]

I think it would be incredibly difficult for someone in a project (like ours!) that was built with micronaut context baked in to be able to take a major update that removed it without a clear pathway for upgrade, be it a plugin or otherwise.

We too have felt much of the pain of the multiple layers of application context and I still don't fully understand it, but that would make an upgrade even harder as we've built a great deal of working code on top of it.

[jamesfredley]

Can you share how you have used Micronaut inside of your Grails App(s). The community steering committee would benefit from your use cases.

Do your use cases map well to using https://micronaut-projects.github.io/micronaut-spring/latest/guide/ directly inside of your Grails app?

[amacleay-cohere]

I'm not 100% positive which micronaut capabilities are dependent on the context implementation v. separable, so listing a large sample of micronaut capabilities I can see we're using at a glance (not a complete list but a reasonable sample)

• All of our built-in HTTP clients are Micronaut declarative HTTP clients
• We are using micronaut AOP
• We use the micronaut scheduled jobs features
• Using micronaut ConfigurationProperties to build configuration objects
• Using micronaut ClientFilterChain
• Using micronaut JacksonFeatures
• Many of our service beans are javax Singletons rather than grails services and refer directly to micronaut application context

I'm not already familiar with https://micronaut-projects.github.io/micronaut-spring/latest/guide/ but it does look as though it does attempt to address many (perhaps not all) of those concerns

[matrei]

I think this change warrants more investigation and testing than we have time for, before releasing Grails 7.
Postponing this to Grails 8 would be wise.

[codeconsole]

Thanks @codeconsole. I can see the plugin incompatibility issue to be less important than making Grails thinner, faster and keeping it up to date to Java/Groovy.

@ppazos I am not sure if you understood my point. EVERY existing plugin will not work with Grails 7. So at a minimum you can expect 6 months for plugins to catch up.

The point being there will be significant time after the 7.0 release to look at a Micronaut plugin or something like that. There will be a whole range of issues between that time that will need to be addressed prior that would prevent anyone dependent on Micronaut from upgrading anyhow.

My contribution goal for 7.0 and what I want to focus on is removing as much bloat as possible and to make Grails as DRY as possible. I am sick of deploying 100MB+ jars.

I don't see how this is related to Micronaut, except that most developers that were working on Grails started working on Micronaut instead.

@matrei Grails was abandoned with the introduction of Micronaut. It was only added, in my option, as an exit strategy from Grails. Grails doesn’t do anything with the numerous extra jars other than, like you said, provide a pathway for people to migrate off of Grails. Beyond that, there are hundreds of Micronaut/Grails/Spring classes with duplicate names that accomplish the same thing, but are in different packages and do nothing but bloat an already bloated framework. Grails 6 is nothing more than Grails 5 with a lot of good things deleted and a switch from one deprecated JVM to a ”modern”, yet antiquated JVM that nobody uses. In the same amount of time it took Grails to go from 5 to 6, @rainboyan (1 person) took made Grails 5 work with Groovy 4 and Spring Boot 3.

Because Grails does nothing with Micronaut and doesn’t depend heavily on anything from it, it is a simple removal. As I already mentioned, I have no problem being the one to create the pull request to remove it. I have a bad taste in my mouth still from Micronaut after it bloated Grails more, took away from the community, and left an expectation of offering GSP only until years passing to crush all hopes of that ever happening.

[ppazos]

@codeconsole I get it. IMHO Grails shouldn't be released if the core plugins are not there. A basic app with web, services and persistence should at least be possible with V7.0.0.

[codeconsole]

@ppazos the problem is Grails is 100% dependent on the community. There is no longer a single organization behind it. Releasing 7 without the core plugins could promote more community involvement. Especially when it comes to updating the plugins.

BTW, nobody is rushing getting 7.0 out. There will obviously be a lot of snapshots, milestones, and release candidates prior to that happening.

[ppazos]

Thanks @codeconsole it's more clear, I was thinking on the v7.0 release after any snapshot/alphas/betas/... because releasing something that doesn't have the minimal MVC ready might be counterproductive.

What do the hardcore Grails devs think about giving a community workshop on the internals of Grails with the goal of providing the minimal info so people contribute for Grails core and core plugins? @jamesfredley mentioned something like that on Slack, it might be nice to have more people involved.

[jeffscottbrown]

Grails was abandoned with the introduction of Micronaut. It was only added, in my option, as an exit strategy from Grails.

FYI... I was involved in those discussions and I never heard anyone talking about it as an exit strategy from Grails. It was definitely not that from my perspective.

[gsartori]

@rainboyan I am secretly praying that you can contribute to Grails removing Micronaut since you have done it in Grace. I know, please don't hate me, we need your help.

[jamesfredley]

Optional, with it being disabled by default (given the survey results and cumulative feedback) is an interesting path.

graceframework/grace-framework@67722d2

graceframework/grace-framework@41f2779

graceframework/grace-framework@a7b883a

[codeconsole]

@rainboyan doesn't making it optional still require including the Micronaut dependencies in applications that do not use Micronaut? Isn't that the reason why you had to rewrite Metadata?

[rainboyan]

@codeconsole I rewrite Metadata because it's the only class that depends on micronaut-inject, Spring Boot has the same API of YamlPropertySourceLoader PropertiesPropertySourceLoader, so prefer to use the Spring Boot one.

[itexto]

The main issue for me is the fact that on Grails oficial documentation we can't see any feature given to us by Micronaut. It only says something like: "by the way, Grails uses Micronaut".

The main question: "what Micronaut brings to the table for Grails developers" is not answered ANYWHERE on the documentation.

If Micronaut brings so much, why such a basic thing (tell the community what it brings) is neglected?

[jeffscottbrown]

"The main issue for me is the fact that on Grails oficial documentation we can't see any feature given to us by Micronaut. " - If that is the main issue for other folks, that is one that is easy to address. This is good feedback.

[rainboyan]

@codeconsole @matrei @jamesfredley All I did was make Grails look normal and make it a true Spring Boot application.

The Grails framework is built on top of Spring Boot and leverages Spring Boot's time-saving features, such as Spring-powered dependency injection.

In fact, it is not. Plugin.doWithSpring() should have been deprecated（Bean definition overriding deprecated in Spring Framework 6.2）in Grails 3.0, and Micronaut Spring should not have been used to rewrite Plugins in Grails 4.0. There are few changes worth mentioning in Grails 5.0 and 6.0. It's time to go back to the way Spring Boot recommends.

It's not the Spring Boot version that lags behind Grails, it's the whole design principle. Grails should take advantage of Groovy and enhance Spring Boot as a powerful option, rather than a replacement to compete with. GSP can be used as a view template engine in Spring Boot, Grails Controllers can be used with Spring MVC, GORM can coexist with Spring Data, etc. Grails' CLI and GSP, Plugins are its most important features, should be enhanced, not stagnant.

Some of the issues I've submitted two year ago still worth figuring out. These issues lead to deeper thinking.

#12389
#12534
#12500
#12471

graceframework/grace-framework@3c20c92
graceframework/grace-framework@d103677
graceframework/grace-framework@e0134ac

[gsartori]

Thinking about Micronaut as a replacement for Spring Boot (as I thought was the reason for the inclusion) the Grails code you describe makes sense. But since that appears not to be the case, I agree with you that the path to Grails 7 goes through simplicity, levereging what Spring has to offer.

I need simplicity. We need simplicity. The world need simplicity (okay, that was gratuitous to keep the discussion on a light tone, but it holds a truth we should consider)

[rainboyan]

Bean overriding has been disabled by default since Spring Boot 2.1, but Grails still use it in 4.0.

Grails’ doWithSpring will not check the Beans whether exists or not, but AutoConfiguration will check first, it will gain better performance.

To Grails, the most important thing is that it will make plugins work better like Spring Boot starters, Grails have DataSource and GSP but they can’t be used in Spring Boot, after migrating to AutoConfiguration, it allows you to use Spring Boot DataSourceAutoConfiguration, Template engines and others, or use the Grails one, you can decide which one to use based on the configuration, rather than just overriding.Most plugins don't need to exist anymore unless they provide more value.

[gsartori]

Grails’ doWithSpring will not check the Beans whether exists or not, but AutoConfiguration will check first, it will gain better performance.

To Grails, the most important thing is that it will make plugins work better like Spring Boot starters, Grails have DataSource and GSP but they can’t be used in Spring Boot, after migrating to AutoConfiguration, it allows you to use Spring Boot DataSourceAutoConfiguration, Template engines and others, or use the Grails one, you can decide which one to use based on the configuration, rather than just overriding.Most plugins don't need to exist anymore unless they provide more value.

@osscontributor can we add this to one of the next thursdays meeting agenda? My take on the future of Grails is the same as @rainboyan (with less awareness - unfortunately - of what's under the hood).

[jeffscottbrown]

@osscontributor can we add this to one of the next thursdays meeting agenda?

Done. Thank you!

[davydotcom]

I would like to point out that by removing it, there is a path to getting live reload back and better with HotSwapAgent

[codeconsole]

Another strong reason why we should remove it.

[gsartori]

That by itself is THE reason to remove it

[jamesfredley]

I believe between https://github.com/orgs/grails/discussions/13517#discussioncomment-10466118 and some other similar work shared in the slack channel, the Micronaut Parent Context can be disabled by default (since 90% are not using it) for new grails apps and simply enabled by adding a few dependencies and possibly a little configuration (which can be wrapped into an optional Micronaut Context feature in Grails Forge).

This allows default grails app to achieve the goals of a single application context to support live reload and smaller deployments and still supports Users who want to use the Micronaut Parent Context with a simple path.

It's a win/win.

[codeconsole]

Based on the Grails Weekly Meeting today, Graeme pointed out the best way forward for people using Micronaut with Grails is to use the Micronaut Spring Boot Starter. This will be the ideal pathway for people wanting to use Micronaut in 7.0

https://micronaut-projects.github.io/micronaut-spring/latest/guide/#springBootStarter

https://github.com/micronaut-projects/micronaut-spring/blob/5.8.x/spring-boot-starter/src/main/java/io/micronaut/spring/boot/starter/MicronautImportRegistrar.java