My view is the library provides convention over configuration and should not be removed by default. People always have the option to remove it from their dependency list.
We can make it better though: 1. The `log` should support a static context (the ticket Jeff mentioned) 2. Grails should provide a `gdsl` for any feature the framework adds outside of your own code. This will allow intellij community edition to autocomplete (understand the log variable existence) and, as we ship new features, IntelliJ would become immediately aware of them. It will also allow us to control our future for Grails IntelliJ support. This can also be the first steps to our own plugin given the lack of Jetbrains' support (see https://github.com/grails/grails-core/issues/13910 for examples). 3. We should revisit the dependencies that have to be included in build.gradle. Over time, several dependencies have been split into separate gradle projects (often for good reason), but we haven't made it easier on the end user to understand what's required. I'm in favor of creating a set of projects that do nothing more than export a batch of dependencies. This allows one line build.gradles for a basic gradle app. I recently fixed the grails-dependencies project in grails-core and it appears that this was an attempt at that - but it hasn't worked since the new gradle scopes were introduced. If we take this approach, I think we can make both sets of people happy - those that want it by default and those who do not. -James On Wed, Mar 12, 2025 at 6:02 PM Mattias Reichel <mattias.reic...@gmail.com> wrote: > Thanks for your input! > > I fully embrace the Convention over Configuration philosophy as the > backbone of Grails. > However, for grails-logging, I'm not sure if it's helping or hurting. > Thanks to Groovy, we already have clean and powerful log object > configuration/injection out of the box. > For Slf4j and other logging frameworks, which work universally on any class > - not just Grails artifacts (which can be a source of confusion). > > It's not like you have to "configure" a whole lot to get the exact same > functionality. > Or, as Jeff and Gianluca has shown, actually even better functionality, > with logging in static context and IDE support. > > I'm also, like Gianluca, advocating for cleaning up and clarifying the > Grails dependencies to make it easier for new developers to grasp, and > every little step helps towards that goal. > > When I say maintain, I also mean having another project in the repository, > dependency in the build file, jar on the classpath and section in the > documentation. > > Den ons 12 mars 2025 kl 20:12 skrev Gianluca Sartori <g.sart...@gmail.com > >: > > > We are also explicitly adding @Slf4j where we need logs so we can have > auto > > completion with IntelliJ Community Edition. > > > > Another plus is that the “log” usage is documented by the annotation. > > > > I have this idea we should define the “conventions” to help Grails be > > perceived less “of the elite” and more “of the people” to raise adoption. > > > > Having auto completion working out of the box from the IDE without the > > Grails plugin is one step on that direction (yes we should have an open > > source IDE plugin…) > > > > That would be my reason to document and promote the usage of the @Slf4j > > annotation. > > > > I personally also like cleaning up Grails 7 dependences if there is no > need > > for them. > > > > Gianluca Sartori > > > > > > On Wed, 12 Mar 2025 at 18:06, Mattias Reichel <mattias.reic...@gmail.com > > > > wrote: > > > > > In my Grails applications, I remove the grails-logging library and > > > explicitly annotate classes with @Slf4j where logging is needed. > > > > > > My question is: Is it worth maintaining a library whose sole purpose, > as > > > far as I know, is to automatically add @Slf4j to all Grails artifact > > > classes? > > > > > >
