Closed tkgregory closed 1 week ago
Thank you for your interest in this plugin.
This looks like another symptom of #12. There is a compatibility issue with the Spring Dependency Management plugin. I need to dig into that to figure out what's happening.
Replaced by:
Many thanks for this plugin! The detection part is working great for me, but I have a query on the configuration part.
Recommended approach
Within a Gradle project I'm apply 2 Spring Boot dependencies:
And I have a simple application class to show me what logging implementation is being used.
Spring Boot's recommends using a module replacement rule to remove the default logback implementation from spring-boot-starter-web and replace it with log4j2.
This works great when I run the application.
Doing the same thing with the logging-capabilities plugin.
I remove the module replacement rule, apply the plugin, and call
enforceLog4J2()
as per the build.gradle.kts below.But I get an error at runtime.
What I found so far
The error comes because org.slf4j:slf4j-api that contains
import org.slf4j.Logger;
isn't on the runtime classpath.Using the module replacement rule, in the dependencies task output we see slf4j-api brought in by log4j-slf4j-impl.
Using the logging-capabilities plugin, we see that log4j-slf4j-impl doesn't bring in any transitive dependencies, as it does above:
It could be quite helpful for Spring Boot developers to be able to use this plugin rather than use the module replacement rule.
Is my intended use case supported?