Grails Maven Plugin

Inlining the exchange from the mailing list

Hi,

I noticed the switch to slf4j in 1.1-beta2 and here are some questions/feedback:

1/ Standalone grails framework : Since you are using slf4j whose main reason for existence is that a developers/deployer could pick up any logging system (log4j, jdk,logback,simple,nop) but the fact that the binding for log4j (slf4j-log4j12-1.5.2.jar) is present in the lib folder and is put on classpath sort of defies its purpose.

on the other hand I do appreciate its (slf4j-log4j12-1.5.2.jar) existance in the grails distribution as it simplifies the life for people sticking with log4j

workaround is that developer removes slf4j-log4j12-1.5.2.jar from the lib directory and drop the appropriate binding of his choice on the classpath

2/ Mavenized grails framework: The problem/limitation becomes bit severe as in most of the grails artifacts dependency slf4j-log4j12-1.5.2.jar is hardcoded. One has to go manually and comment this dependency ( I do not even know what are the other implications of this type of modification!!!).

This is also against what has been recommend on http://www.slf4j.org/faq.html#maven2

<from_slf4j_faq>

What about Maven2 transitive dependencies?
As an author of a library built with Maven2, you might want to test your application using a binding, say slf4j-log4j12 or logback-classic, without forcing log4j or logback-classic as a dependency upon your users. As of SLF4J version 1.3, this quite easy to accomplish. But first, since your library's code depends on the SLF4J API you will need to declare slf4j-api as a compile-time (default scope) dependency.

<dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> <version>1.5.6</version> </dependency>

Limiting the transitivity of the SLF4J binding used in your tests can be accomplished by declaring the scope of the SLF4J-binding dependency as "test". Here is an example:

<dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-log4j12</artifactId> <version>1.5.6</version> <scope>test</scope> </dependency>
Thus, as far as your users are concerned you are exporting slf4j-api as a transitive dependency of your library, but not any SLF4J-binding or an underlying logging system.

</from_slf4j_faq>

For maven I think that instead of putting the dependency on bindiing slf4j-log4j12 in grails-* pom files if it could be put in the application's pom file it may be good as later this binding can be replaced with some other by the developer. I have tried it locally and seems to work.

Please comment or suggest if my understanding is incorrect.

Regards & thanks
Kapil

> For maven I think that instead of putting the dependency on bindiing
> slf4j-log4j12 in grails-* pom files if it could be put in the application's
> pom file it may be good as later this binding can be replaced with some
> other by the developer. I have tried it locally and seems to work.
>
> Please comment or suggest if my understanding is incorrect.

I totally agree. Could you raise a JIRA as a sub-task of:

http://jira.codehaus.org/browse/GRAILS-3547

Thanks,

Peter

Done, but unfortunately Grails is hard-coded to Log4J at the moment because of the configuration aspect. We need to decouple the logging configuration from Lo4J somehow, but it's unlikely to occur for 1.1.

Actually that's not quite true: you can depend on slf4j-jdk14 for example as long as you also include log4j as a dependency too. A bit of a hack, but seems to work.