grails
Grails 7 Scope - Remove Micronaut Context #13517
Replies: 10 comments 43 replies
-
|
Removing Micronaut Context as the parent context of the Spring Boot context means you would not longer be able to:
|
Beta Was this translation helpful? Give feedback.
-
|
remove context = one less resource to maintain. |
Beta Was this translation helpful? Give feedback.
-
|
From a technical point of view I would love to have Grails based entirely on Micronaut, we are using Micornaut for services. From an architectural and business point of view though, I would keep dependencies as low as possible. Having both Spring and Micronaut on Grails is a duplicate. Except from a different API we can do everything with spring (even though I may like it’s API or not, that’s not an issue from this POV) From a CTO point of view I would choose Spring just because it’s the most used one. Using Grails is already an hazard, but I realise it lowers the costs of onboarding junior devs and its level of abstraction is not far from the other frameworks so we can “reuse” the competences developed working with it. I started working with Grails from version 2 and I have a strong consideration for all the people working on Groovy, Grails and Micronaut. You are an inspiration to me. It is hard for me to say that we need to keep Micronaut out of Grails. What I can think of at the moment would be to create an abstraction layer within Grails so it can be built on top of Spring OR Micronaut. I have no idea if it’s feasible. In the end Grails is the “Conventions over Configuration” layer on top of a web framework. It should not be much heavy but more on the light side in my opinion. Anyway, whatever happens in the future, I appreciate so much the work you have done with Grails. It made possible for small teams to develop web applications with small budgets and this by itself is a win. |
Beta Was this translation helpful? Give feedback.
-
|
@gsartori arguments resonate with me, though I don't use Micronaut, and it seems what Micronaut adds is support for Micronaut things, which IMO we would like Grails to use Grails things, and Micronaut to be an option for the ones who need it. So for me is a "leave it out". |
Beta Was this translation helpful? Give feedback.
-
|
If Micronaut was to be come a plugin, so it became an optional plugin, I would see that as a big plus. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
@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 :) |
Beta Was this translation helpful? Give feedback.
-
|
"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! |
Beta Was this translation helpful? Give feedback.
-
|
@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? |
Beta Was this translation helpful? Give feedback.
-
|
"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! |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
There is a work-in-progress PR currently updating to Micronaut 4.5.3 #13545 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
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)
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 |
Beta Was this translation helpful? Give feedback.
-
|
I think this change warrants more investigation and testing than we have time for, before releasing Grails 7. |
Beta Was this translation helpful? Give feedback.
-
@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.
@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. |
Beta Was this translation helpful? Give feedback.
-
|
@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. |
Beta Was this translation helpful? Give feedback.
-
|
@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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
@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. |
Beta Was this translation helpful? Give feedback.
-
|
Optional, with it being disabled by default (given the survey results and cumulative feedback) is an interesting path. graceframework/grace-framework@67722d2 |
Beta Was this translation helpful? Give feedback.
-
|
@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? |
Beta Was this translation helpful? Give feedback.
-
|
@codeconsole I rewrite Metadata because it's the only class that depends on micronaut-inject, Spring Boot has the same API of |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
"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. |
Beta Was this translation helpful? Give feedback.
-
|
@codeconsole @matrei @jamesfredley All I did was make Grails look normal and make it a true Spring Boot application.
In fact, it is not. 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. graceframework/grace-framework@3c20c92 |
Beta Was this translation helpful? Give feedback.
-
|
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) |
Beta Was this translation helpful? Give feedback.
-
|
I would like to point out that by removing it, there is a path to getting live reload back and better with HotSwapAgent |
Beta Was this translation helpful? Give feedback.
-
|
Another strong reason why we should remove it. |
Beta Was this translation helpful? Give feedback.
-
|
That by itself is THE reason to remove it |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
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.
65 votes ·
Beta Was this translation helpful? Give feedback.
All reactions