For what it is worth, I had no idea that's what was being done automatically. I'd say grails-logging promotes convention over configuration.
Looking over the source code for grails-logging, it seems like it would not be too difficult to maintain given how few lines of code there are. https://github.com/grails/grails-core/tree/7.0.x/grails-logging And the source code itself hasn't changed much over the years. https://github.com/grails/grails-core/commits/d495ae5f3a6c1cb10e93afa44ba8bc3919eaa10a/grails-logging/src/main/groovy/org/grails/compiler/logging/LoggingTransformer.java https://github.com/grails/grails-core/commits/d495ae5f3a6c1cb10e93afa44ba8bc3919eaa10a/grails-logging/src/test/groovy/org/grails/compiler/logging/LoggingTransformerSpec.groovy But I haven't done anything on Grails 7 development, so I wouldn't know if grails-logging has been a pain point for upgrades. On Wed, Mar 12, 2025 at 1:08 PM Mattias Reichel <[email protected]> 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? >
