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?

[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

[supsup]

Fair enough, was a bit extreme.

[jamesfredley]

Gradle is going to be a limiting factor on the maximum supported Java version for Grails 7.

Gradle 7.6.4 (the latest 7.x version), used on Grails 6.2, supports up to Java 19. Gradle 8.5 is required for Java 21 support. The Grails code is not yet Gradle 8.5 compatible and there will be some level of effort to get there.

https://docs.gradle.org/current/userguide/compatibility.html

[gsartori]

@jamesfredley I guess we should target the latest Java and Gradle versions for Grails 7 then. It is a bit unfortunate that Gradle does not have an LTS policy that makes sense, they are forcing everybody to follow their speedy evolution with small to no real reasons to move from one version to the next one. I used to like Gradle for its clean configuration style. Today I just wish that Maven could be configurable with YAML instead of XML and I would switch to it immediately. The build system CANNOT be a budget wasting tool.

[jamesfredley]

It would be nice for Gradle to add support for new Java versions without forcing you to address all of the features that were removed or changed with the Gradle latest version. It is a time suck, especially on a large project with a ton of Gradle config that was created over a long period of time.

There is a difference between the Java version Gradle supports for the build and version Grails will run on, even with 6.2.

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

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

[osscontributor]

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/