Marketing Groovy, GORM & Grails

[gsartori]

Searching the web it looks like we are dead (or dying). Just look at the dates on any Grails related searches.
Groovy is a bit better thanks to Paul King's blog posts.

My opinion is that part of the Grails project is to communicate Groovy, GORM and Grails itself.

I'm opening this discussion as a way to track marketing ideas, proposals and actions to improve the communication of Groovy, GORM and Grails.

[gsartori]

IntelliJ has an open-source page reporting all the most important web frameworks/languages foundations.
Groovy & Grails is not one of those.

I have no idea about what it takes to be there, but that's a promotional page that can give confidence to people to adopt Grails (or at least give it a try) (or at least be aware of).

Should we be there with the other cool guys?

[snimavat]

We/Grails was once the "cool guy" on the street

[itexto]

I recently asked on Reddit about the relevance of Groovy today. The .aí. feeling is that yes, we are dying.

https://www.reddit.com/r/groovy/s/xKypXEX6va

[jamesfredley]

Several Grails projects have been updated to Gradle 8.10, which supports up to Java 23. There is still more work remaining, but good progress so far.

[rlconst]

We have a multi-module project and grails effectively bottleneck for upgrading gradle which itself is a bottleneck to update another frameworks e.g. micronaut

[jamesfredley]

Grails 7 is currently using Gradle 8.10.2. You can preview the SNAPSHOTs on https://github.com/jamesfredley/grails-website-test

[snimavat]

It feels so sad, we had a very thriving community

[jamesfredley]

The mojo is rising with Grails 7. https://grails.org/blog/2024-10-01-grails-community-contributions.html

[TheRetroRoot]

Move to another chat system. Since Slack deletes messages after 10k, it's basically deleting the value of the community. I know there are external logging things that can be used. But really, visiting the chat and seeing no history really adds to the "dead community" vibe.

Move to something like Discord which has tools in place to begin rebuilding the community and creates opportunities for engagement. There are some great tools available for Discord which would allow us to begin having virtual conferences, workshops, and more.

[gsartori]

I've created a Discord channel if we want to experiment with it, who should be added as administrator?

https://discord.gg/z8uWkqpw

[TheRetroRoot]

I manage a few different Discord servers and am happy to pitch in on admin work + setting it up for use.

[sdelamo]

I am not sure moving the community to a new chat system is a good idea in this moment of the framework.

[gsartori]

@sdelamo it can be energising though, we need energy now, we need “new things”, new people, new energies. We need fresh air to breath again.

[sbglasius]

Groovy slack is mirrored here: https://groovy.linen.dev/ and Grails slack is mirrored here: https://grails.linen.dev/ - both with retained history. But I agree that moving away from Slack to any (free) platform would be better.

[monetschemist]

I've used Groovy and Grails since 2010 or so. The only "real" web apps I've built have been with Grails. Said that, I don't spend my days developing stuff in any language / framework; it's what I do occasionally as the need in my work arises. Beyond that, I've written about Groovy on https://opensource.com/users/clhermansen and on https://opensource.net/author/chrishermansen/ My comments below about "marketing Grails" come from this perspective.

Things I feel contribute to a sense of "Grails being dying or dead":

1. out-of-date tutorials (sometimes very out of date) e.g. https://guides.grails.org/building-a-react-app/guide/index.html is based on Grails 3.3.5
2. superficial documentation that offers limited explanation, doesn't drill down into more complex examples and doesn't explicitly state best practices e.g. https://gorm.grails.org/latest/hibernate/manual/index.html#gormAssociation which avoids the semantic distinction between many-to-one as a "lookup relationship", using the Nose-Face example (which probably is not going to be a lookup relationship but rather a parent-child relationship), which offers the idea of cascading saves (implicitly for parent-child relationships, but does it also work for "lookup relationships" where there is no "belongs to", etc)
3. lack of up-to-date third party reference material e.g. Burt Beckwith's exceptionally useful Programming Grails: Best Practices for Experienced Grails Developers is based on Grails 2.0, Smith and Ledbrook's _Grails in Action- is based on Grails 2.0, etc.

I get that updating these things requires significant commitment on the part of volunteers (especially writing books), and that in some cases a sense of "dead or dying" is a self-fulfilling prophecy (for example, is O'Reilly or Manning interested in a new book on Grails?). So this is tough, but I see these three points as a collectively LARGE barrier for new Grails users to overcome.

Besides those three points, I understand the concerns voiced over up-to-date support for IntelliJ and VS Code, as I imagine many (most?) developers either use one of those by choice or are required to by their employers.

The issue of Grails dependencies being behind seems an important one as well. The whole business of having to stick with Java 8 for so long offered the obvious conclusion that Grails was not keeping up with the times.

What to do about this? I would be happy to help with updating and enhancing documentation, like tutorials, including preparing a GORM tutorial with more real-world semantics. I assume such things are addressed with pull requests, but the kinds of changes I propose may run a bit deeper than correcting typos. Is this a worthwhile thing to undertake?

[monetschemist]

Ok, I'm going to pick a tutorial that deals with a topic I feel matches my ability to contribute, then I will review it to see what I don't understand and ask whatever questions I need to clear up on the Slack channel, then make my changes, then submit the PR. Sound OK?

[jamesfredley]

Sounds great.

[jeffscottbrown]

for example, is O'Reilly or Manning interested in a new book on Grails?

I don't know about O'Reilly but both Manning and Apress have expressed interest at times during the years since the most recent Definitive Guide To Grails books were published.

[monetschemist]

I would love to see the Definitive Guide to Grails updated. I would love to contribute to that. I feel I am limited by my lack of knowledge of "best practices" in the newer versions of Grails. For example, all the new (to me at least) annotation stuff in the services layer - I understand the indications given in the official docs but I don't see how that orients me to best practices. Another example, I feel there must be great utility to command classes, but my current level of knowledge is that they are mostly useful for decoupling validation from domain classes (and I'm not sure why I would want to do that, since I don't see a huge opportunity to share validation between different domain classes).

[sbglasius]

There was also a book by @erichelgeson on Grails 3, that you could buy online. Unfortunately that is now taken off-line. Perhaps it could be revitalized?
The last time it was visible was here: https://web.archive.org/web/20191213200212/https://www.grails3book.com/

[ewcole]

I think the real problem is a lack of commitment to backwards compatibility from the developers of Groovy and Grails. I've written a lot of applications in Grails 2.5, and would be happy to stay with it forever if it weren't a sinking ship. But subsequent versions of Grails have changed so much that it is like learning a completely new framework, and who has time for that? This is especially painful if you are trying to do anything beyond the examples on the basic tutorial, which is just when you look for sample code on Stack Overflow or blog posts. If you didn't break the existing code, then you could keep using the old documentation forever.

In contrast, I could run any PL/SQL code that I've written in the last 20 years without any changes whatsoever. I never waste time on the squirrel cage when I use that tool.

Forgive me if I sound critical, but I am very frustrated, and I am beginning to think that I made a serious mistake when I bet the farm on Grails.

[itexto]

You know something that was a mistake in my opinion? The removal of the "grails upgrade" command. Em qua., 20 de nov. de 2024 às 17:53, Ed ***@***.***> escreveu:

…

I think the real problem is a lack of commitment to backwards compatibility from the developers of Groovy and Grails. I've written a lot of applications in Grails 2.5, and would be happy to stay with it forever if it weren't a sinking ship. But subsequent versions of Grails have changed so much that it is like learning a completely new framework, and who has time for that? This is especially painful if you are trying to do anything beyond the examples on the basic tutorial, which is where you look for sample code on Stack Overflow or blog posts. If you didn't break the existing code, then you could keep using the old documentation forever. In contrast, I could run any PL/SQL code that I've written in the last 20 years without any changes whatsoever. I never waste time on the squirrel cage when I use that tool. Forgive me if I sound critical, but I am very frustrated, and I am beginning to think that I made a serious mistake when I bet the farm on Grails. — Reply to this email directly, view it on GitHub <#13559 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC6W7AASVKVGTXUBN5PM4TL2BTZEVAVCNFSM6AAAAABLCQTY2WVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMZSHA2TSMA> . You are receiving this because you commented.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]

FYI... #13784

[itexto]

Wonderfull Jeff! Good move! Em qui., 21 de nov. de 2024 às 16:27, Jeff Scott Brown < ***@***.***> escreveu:

…

FYI... #13784 <#13784> — Reply to this email directly, view it on GitHub <#13559 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC6W7AD6JGNID7JUSMFLMPL2BYX2JAVCNFSM6AAAAABLCQTY2WVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMZUGA2DSOI> . You are receiving this because you commented.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