I’ve been thinking about it a lot today. The value of Grails is its ability to promote best practices through the adoption of the “conventions over configuration” paradigm applied to Spring with a bit of sugar from Groovy. But from a business point of view this lets us onboard people faster and recruiting less expert people. It also helps building applications with lower mainteining costs (okay, this is debatable). This is already a big value. We don’t need more innovation from Grails, we just need it to stay relevant updating its dependencies - I would say - ONLY because nowadays security is a thing and it MUST be taken care of. We don’t need Grails to depend on Micronaut. I love Micronaut but maybe the decision of including it instead of investing upgrading Groovy, Spring and Gradle to their latest versions has not been the best one. A software today is easily perceived as affected by “technical debt” if it’s not up to date with the latest versions of its dependencies. I think that @Michael Yan with its Grace Framework took a better decision: less dependencies, more relevance. Grails may SWITCH to Micronaut once and IF it will be ready for that, completely substituting Spring. We need something like Grails, the whole hype about the cloud and the microservices is good for big corporations but is very dangerous for small/medium enterprises. Not all businesses need to scale to million of users (namely any B2B business does not fit that scenario) and not all big data must be sent to the cloud using huge bandwidth (I’ve seen it) and consumed from a web dashboard. And we are not talking about lock-ins yet... Okay, the topic may gets huge, but the point is that Monolith applications are not evil. There is a place for Grails and maybe one of the reasons why it’s loosing traction could also be because when you look at it you see outdated and not supported dependencies. I don’t know if someone from OCI or Grails Foundation is reading this but we may “Keep it simple” and maybe take a step back just releasing an updated Grails which basically means merging the work done by @Michael Yan. If the Grails Community is really made of a couple of people like it seems we should not waste effort and try working as a team instead of diverging. So, to make it simple and embarrassingly clear: OCI, are you open to discuss the direction that Grails took during the last years and merge the work done by @Michael Yan? One of the Masters I’ve encountered in my life once told me “Adding is easy, removing is hard.” If Grails is already dead within OCI, if there is no Grails team anymore, then I guess we should give Grace a chance and start helping Michael.

@giangio Thank you for mentioning me and the Grace framework, I'm glad you like Grace too, in the past year or so, I have put a lot of effort into developing Grace, going through 70 version iterations, close to 4000 commits, refactoring most of the modules, including the underlying Core API, Plugins, Profiles, CLI, and a large number of third-party dependency updates, so that Grace is designed according to the Spring Boot-compliant architecture, It is also more compatible with other frameworks and libraries in the Spring ecosystem.

From a business point of view the decisions you have taken to update all the relevant dependences and removeing the "duplicate" ones is convincing (to me). We dont need something more than a "Convention over configuration" (tiny) layer on top of Spring or Mironaut (I personally would not have both of them on the same release). Of course I would like to see just one Grails, but if its not possible my preference would go with the "cleaner" one. Simple things work, complicated ones don't.

Has there been any news or updates from the Grails Foundation since the Object Computing announcement? Does anyone know how up to date the advisory board is? Are any of these people still involved? https://grails.org/foundation/

+