at want it by default and
those who do not.
-James
On Wed, Mar 12, 2025 at 6:02 PM Mattias Reichel
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
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.
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
wrote:
> In my Grails applications, I remove the grails-logging library and
> explicitly annotate classes with @Slf4j where logging is needed.
>
>
My view is one of Grails core raison detre is to assert Convention over
Configuration and this moves that agenda forward.
On Wed, Mar 12, 2025 at 1:08 PM Mattias Reichel
wrote:
> In my Grails applications, I remove the grails-logging library and
> explicitly annotate classes with @Slf4j
ove 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?
>
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
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?
