logback (or any SLF4J impl, for that matter) shouldn't probably be shipped with robot-server-plugin
PawelLipski opened this issue · comments
Note that IntelliJ has its own implementation SLF4J bundled, and hence running IntelliJ with the plugin leads to a SLF4J warning:
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/home/plipski/intellij-ui-test-robot/robot-server-plugin/build/idea-sandbox/plugins/robot-server-plugin/lib/logback-classic-1.2.11.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/home/plipski/.gradle/caches/modules-2/files-2.1/com.jetbrains.intellij.idea/ideaIC/LATEST-EAP-SNAPSHOT/1d1379e000cefa3de748ead2a1b3702ef1798bf4/ideaIC-LATEST-EAP-SNAPSHOT/lib/3rd-party-rt.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [ch.qos.logback.classic.util.ContextSelectorStaticBinder]
Would it make sense to remove the dependency on logback from robot-server-plugin/build.gradle.kts + also remove logback.xml in this module? The exclusion of slf4j-api is still a good idea, can in fact be done globally (and not on a per-dependency mode) as in e.g. this plugin of ours.
As a bonus, removing logback dependency automatically solves #190, as I've just checked.
Logs from Ktor/Netty can still be controlled via IntelliJ's centralized Debug Log Settings if absolutely needed.
good point! +1 to this one
when to expect that this issue will be completed ?
when to expect that this issue will be completed ?
😌
Hello, I'll publish a new version this evening, it will include the fix
Done in v0.11.15