Logging configuration for custom Gradle plugin that has libraries in its dependency graph that depend on logging APIs such as JCL, Log4J1/2

I know the topic of logging from custom Gradle plugins has been discussed multiple times already, but there is one more aspect that I couldn’t find information about.

Consider I’m developing a custom Gradle plugin, say p, that uses an external library, say l. Assume l depends (transitively) on logging APIs such as Java Logging, Apache Commons Logging, Log4J1/2 (i.e., p transitively has one ore more of them in its dependency graph; and no matter whether they are implementation or runtime dependencies).

We know that Gradle itself uses SLF4J as its main logging API. Now, do I as the developer of p need to take care of replacing any of such (transitive) dependencies with the corresponding redirection library to SLF4J; that is, with

org.slf4j:jul-to-slf4j
org.slf4j:jcl-over-slf4j
org.slf4j:log4j-over-slf4j
org.apache.logging.log4j:log4j-to-slf4j

respectively? Such that any log call to any of these libraries eventually ends up in Gradle’s logging backend(s)? Or does Gradle itself already take care of including these redirections?

Gradle should already handle that for you and if it does not work for one of the common frameworks it should probably be a feature request ticket.

In the case of jul-to-slf4j you would be lost anyway, as for that to work you have to set a system property before the first JUL class is loaded, so you couldn’t do it in a plugin anyway.

Here also a strong hint:

$ find ~/.gradle/wrapper/dists/gradle-8.0.1-bin/ -type f -name '*slf4j*'
~/.gradle/wrapper/dists/gradle-8.0.1-bin/7rsvvmdp4bsd5fhm7a9cyrnzz/gradle-8.0.1/lib/jcl-over-slf4j-1.7.30.jar
~/.gradle/wrapper/dists/gradle-8.0.1-bin/7rsvvmdp4bsd5fhm7a9cyrnzz/gradle-8.0.1/lib/jul-to-slf4j-1.7.30.jar
~/.gradle/wrapper/dists/gradle-8.0.1-bin/7rsvvmdp4bsd5fhm7a9cyrnzz/gradle-8.0.1/lib/log4j-over-slf4j-1.7.30.jar
~/.gradle/wrapper/dists/gradle-8.0.1-bin/7rsvvmdp4bsd5fhm7a9cyrnzz/gradle-8.0.1/lib/slf4j-api-1.7.30.jar

Great! Seeing that they are distributed together with Gradle answers everything :slight_smile: