[ https://issues.apache.org/jira/browse/ZOOKEEPER-4820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17835538#comment-17835538 ]
Piotr Karwasz commented on ZOOKEEPER-4820: ------------------------------------------ In this case I find both the {{optional}} attribute and the {{provided}} scope inappropriate for the {{zookeeper}} artifact. If Zookeeper were to have an {{optional}} dependency on Logback, it might suggest that some part of Zookeeper uses Logback *directly*, e.g. to manage and change log levels. AFAIK it is not the case. If Zookeeper were to have a dependency on Logback in the {{provided}} scope, I would interpret it as a strict requirement to have Logback on the runtime classpath. AFAIK any other logging backend will work as well. > zookeeper pom leaks logback dependency > -------------------------------------- > > Key: ZOOKEEPER-4820 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4820 > Project: ZooKeeper > Issue Type: Task > Components: java client > Reporter: PJ Fanning > Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > Since v3.8.0 > https://mvnrepository.com/artifact/org.apache.zookeeper/zookeeper/3.8.0 > It's fine that Zookeeper uses Logback on the server side - but users who want > to access Zookeeper using client side code also add this zookeeper jar to > their classpaths. When zookeeper is used as client side lib, it should > ideally not expose a logback dependency - just an slf4j-api jar dependency. > Would it be possible to repwork the zookeper pom so that client side users > don't have to explicitly exclude logback jars? Many users will have their own > preferred logging framework. > Is there another zookeeper client side jar that could be instead of > zookeeper.jar? -- This message was sent by Atlassian Jira (v8.20.10#820010)