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.

We are also looking for someone to contribute to a few Micronaut tasks in preparation for Grails 7

grails/grails-doc#912

grails/grails-functional-tests#241

[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]

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.

No, you cannot and I want Grails to go the way most people want, not my way.

[ysb33r]

That being said, are you sure you won't be able to do what you want using the Micronaut/Spring integration? I want things to be as painless for you as possible.

We might be able to, but we try to avoid bringing Spring into our Micronaut applications.

[rlconst]

It will be awesome if grails will have a clear guide how to use micronaut via spring boot starter. Or probably have a tiny wrapper just for declarative http client

[codeconsole]

We might be able to, but we try to avoid bringing Spring into our Micronaut applications.

@ysb33r isn't that what you would be doing either way if we kept Micronaut in Grails how it was?

[jamesfredley]

@rlconst

We are also looking for someone to contribute to a few Micronaut tasks in preparation for Grails 7

grails/grails-doc#912

grails/grails-functional-tests#241

[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

[jamesfredley]

We are looking for someone to contribute to a few Micronaut tasks in preparation for Grails 7

grails/grails-doc#912

grails/grails-functional-tests#241

[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

[itexto]

I repeat: all these issues would be no issues if since the beginning was clear for everyone which gains we would have with Micronaut. Today we still don't have this on the core documentation. The benefits to justify a change so great on the core of the framework were never clear for the majority of Grails users. the main benefit would be an improvement on startup times. Did we got it? Nope: still the same problem. Is it easier to generate native binaries with it? No, or at least not clear for everyone else. It looks for me more like a marketing strategy than a technical improvement. Em qui., 14 de nov. de 2024 às 05:56, Constantine ***@***.***> escreveu:

…

It will be awesome if grails will have a clear guide how to use micronaut via spring boot starter. Or probably have a tiny wrapper just for declarative http client — Reply to this email directly, view it on GitHub <#13517 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC6W7AG2WA7F6KSTJVUPSHT2ARQUXAVCNFSM6AAAAABJKNVYY2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMRVGE2TMNQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Henrique Lobo Weissmann Diretor Técnico <https://www.facebook.com/itexto> <https://www.twitter.com/itexto> <https://www.linkedin.com/company/itexto> <https://www.instagram.com/itextobr> *Tel:* +55 (31) 2573-1979 <+55(31)2573-1979> *Email:* ***@***.*** *Web:* www.itexto.com.br

[jeffscottbrown]

It looks for me more like a marketing strategy than a technical improvement.

I appreciate the input but I assure you, it wasn't a marketing strategy. The Marketing team wasn't even involved in the discussions or the decisions. The decision to integrate Micronaut was 100% a technology team decision. I know folks keep saying that it wasn't and I appreciate that perspective, but it really was a technology decision.

[itexto]

I believe in you Jeff. But which were the real benefits that we got with Micronaut? Em qui., 14 de nov. de 2024 às 11:25, Jeff Scott Brown < ***@***.***> escreveu:

…

It looks for me more like a marketing strategy than a technical improvement. I appreciate the input but I assure you, it wasn't a marketing strategy. The Marketing team wasn't even involved in the discussions or the decisions. The decision to integrate Micronaut was 100% a technology team decision. I know folks keep saying that it wasn't and I appreciate that perspective, but it really was a technology decision. — Reply to this email directly, view it on GitHub <#13517 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC6W7ABNSOA4WNSWRFEZ45T2ASXE5AVCNFSM6AAAAABJKNVYY2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMRVGUZDCNI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Henrique Lobo Weissmann Diretor Técnico <https://www.facebook.com/itexto> <https://www.twitter.com/itexto> <https://www.linkedin.com/company/itexto> <https://www.instagram.com/itextobr> *Tel:* +55 (31) 2573-1979 <+55(31)2573-1979> *Email:* ***@***.*** *Web:* www.itexto.com.br

[jeffscottbrown]

"But which were the real benefits that we got with Micronaut?" - It depends on the application, and some may not benefit much, but some do. As an example, it is the case that instead of writing traditional Grails services some folks want to write classes that are configured as Micronaut beans and then inject those beans where they want them into other Micronaut beans and/or into Spring beans. Benefits of that include compile time bean configuration vs runtime bean configuration. Some folks have libraries of Micronaut beans that they consume from both Grails apps and Micronaut apps. Micronaut provides some interesting capabilities like the declarative http client. I think some of Grails internals were rejigged to take advantage of Micronaut. Those are some examples anyway.

For Grails 7 I think the approach the team is taking is to pull most of that out and provide a path for folks to take advantage of those things if they like (except the internal Grails wirings), and for folks who don't want to take advantage of those things then they aren't bringing any of that baggage along in their Grails apps.

[jamesfredley]

https://github.com/orgs/grails/discussions/13517#discussioncomment-10431743 has a good, real world, use case list

grails/grails-doc#912 - for those that took advantage of Micronaut in Grails, this task will document how to do it Grails 7