java 如何在保留 SLF4J 的同时从库的依赖项中删除 logback？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/32231814/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
How can I remove logback from a library's dependency while keeping SLF4J?
提问by Lahiru Chandima
In my Vaadin project, I have a dependency on a certain library. This library uses slf4j for logging. In the library pom, logback slf4j binding is added as a runtime dependency.
在我的 Vaadin 项目中，我依赖于某个库。该库使用 slf4j 进行日志记录。在库 pom 中，添加了 logback slf4j 绑定作为运行时依赖项。
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>${logback.version}</version>
<scope>runtime</scope>
</dependency>
In my application, I directly use log4j for logging. I want the logs added by the library to go in my log4j log.
在我的应用程序中，我直接使用 log4j 进行日志记录。我希望库添加的日志进入我的 log4j 日志。
For this, I added following to my pom to include slf4j log4j binding
为此，我在 pom 中添加了以下内容以包含 slf4j log4j 绑定
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.7.12</version>
</dependency>
However, slf4j complains that it has found multiple bindings.
但是，slf4j 抱怨它发现了多个绑定。
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/D:/program_files/apache-tomcat-8.0.24/temp/0-ROOT/WEB-INF/lib/logback-classic-1.0.13.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/D:/program_files/apache-tomcat-8.0.24/temp/0-ROOT/WEB-INF/lib/slf4j-log4j12-1.7.12.jar!/org/slf4j/impl/StaticLoggerBinder.class]
I checked the dependency tree of my application, which has following for its dependency on logback. (Following is the only dependency on logback)
我检查了我的应用程序的依赖树，它有以下对 logback 的依赖。（以下是对 logback 的唯一依赖）
[INFO] | +- com.mycompany.mylib:libname:jar:1.1.0-SNAPSHOT:compile
[INFO] | | +- org.slf4j:jcl-over-slf4j:jar:1.7.5:runtime
[INFO] | | +- ch.qos.logback:logback-classic:jar:1.0.13:runtime
[INFO] | | | \- ch.qos.logback:logback-core:jar:1.0.13:runtime
[INFO] | | +- ch.qos.logback:logback-access:jar:1.0.13:runtime
Also, when I checked inside WEB-INF\libdirectory in my war file, I found following jars.
另外，当我检查WEB-INF\lib我的 war 文件中的目录时，我发现了以下 jars。
logback-access-1.0.13.jar
logback-classic-1.0.13.jar
logback-core-1.0.13.jar
Why did logback ended up in my lib directory? As I have heard, runtime dependencies should not come into libs directory.
为什么 logback 最终出现在我的 lib 目录中？正如我所听说的，运行时依赖项不应进入 libs 目录。
How should I resolve this? The library is developed within my company and I can ask the library developers to remove the logback runtime dependencies if needed.
我应该如何解决这个问题？该库是在我公司内部开发的，如果需要，我可以要求库开发人员删除 logback 运行时依赖项。
回答by durron597
Option 1: They change their pom.
选项 1：他们改变他们的 pom。
The easiest way to fix this would be to have the library developers in your own company mark logback as optionaland require SLF4J as a compile dependency explicitly. This is the right, canonicalway to do SLF4J in Maven. In other words:
解决此问题的最简单方法是让您自己公司的库开发人员将 logback 标记为可选，并明确要求 SLF4J 作为编译依赖项。这是在 Maven 中执行 SLF4J的正确、规范的方法。换句话说：
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>${slf4j.version}</version>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>${logback.version}</version>
<scope>runtime</scope>
<optional>true</optional>
</dependency>
Option 2: You revise their dependencies in your pom.
选项 2：您在 pom.xml 中修改它们的依赖项。
If you want to fix it yourself, without going through them, then you can use the exclusionstag when declaring their dependency. In other words, in your pom, do:
如果你想自己修复它，而不是通过它们，那么你可以exclusions在声明它们的依赖时使用标签。换句话说，在你的 pom 中，做：
<dependency>
<groupId>your.company</groupId>
<artifactId>libraryname</artifactId>
<version>${theirlibrary.version}</version>
<exclusions>
<exclusion>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
</exclusion>
</exclusions>
</dependency>
You asked if there's an reason to depend on Logback directly; generally there isn't, for a library author. Their pom configuration is probably just a minor oversight on their part. There are some reasons to depend on logback specifically, but they have to do with startup (stuff with JoranConfiguratoror StatusPrinter, that sort of thing, which shouldn't come up with a library. Other reasons to call Logback classes directly include stuff like custom appenders, which, again, shouldn't come up in a library, only a deployed app.
你问是否有理由直接依赖 Logback；对于图书馆作者来说，通常没有。他们的 pom 配置可能只是他们的一个小疏忽。有一些原因需要专门依赖 logback，但它们与启动有关（使用JoranConfiguratoror 之StatusPrinter类的东西，不应该提供库。直接调用 Logback 类的其他原因包括自定义 appender 之类的东西，同样，不应出现在库中，而应出现在已部署的应用程序中。
