You’ve just discovered the build tool equivalent of that unspeakable family secret that nobody here dares talk about 
Tons of people have brought it up over a span of several years:
- Allow slf4j logging during junit tests
- No (slf4j) log messages from executed java class
- Gradle + Logback external logging problem with MDC initializations
- How to Configure Slf4j Logging in a Custom Plugin
- Is it Intentionally Impossible To Use Other SLF4J Impls With The Gradle API?
- Depending on gradleApi() creates multiple bindings for slf4j when I also depend on logback-classic. how can i get around this?
- …etc.
This answer goes out to all of them too 
When the Gradle Tooling API is on your classpath—as it is when you’re developing plugins— Gradle overrides the standard SLF4J API with its own internal SLF4J API plus its own internal implementation.
With those in your classpath, Gradle forbids you from using any other SLF4J API/implementation configuration when you’re developing plugins. Well, you could configure them. They just won’t work the way you expect them to work is all; as you, me and the others above have discovered.
Not the end of the world though. You could still do:
...
import org.gradle.api.logging.Logger;
import org.slf4j.LoggerFactory;
...
public class FooPlugin {
private static final Logger LOGGER = LoggerFactory.getLogger("FooPlugin");
...
public void m(){
...
LOGGER.quiet("...Which is more or less like Logger.debug()... ");
...
}
...
}
Don’t you find it peculiar OP, that there’s no documentation anywhere that explains why Gradle’s logging is the way it is? I do. The user guide doesn’t explain it in enough detail. @Peter_Niederwieser? Would you happen to know of a blog post or anything that explains Gradle’s logging for plugins in detail?