[ https://issues.apache.org/jira/browse/ZOOKEEPER-4820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17831487#comment-17831487 ]
Christopher Tubbs commented on ZOOKEEPER-4820: ---------------------------------------------- Provided scope may achieve the same result for dependency resolution for dependent projects. However, they mean very different things. Provided means it's required, but not expected to be bundled because it is expected to be provided by the destination environment. In this case, we want the opposite: it's not required, but is expected to be bundled. However, there may be times where you need to use provided instead of using optional, because you need it to be handled in a specific way by a Maven plugin during the build, because different plugins do different things with these. For this, the correct way of doing it that communicates the relevant intent is to mark it optional and keep the scope as runtime. However, if provided is needed instead, to make a particular plugin work, you should be prepared to cause other problems downstream, and at the very least, you should add a comment in the POM explaining why provided is used instead, so the intention is clear. > 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 > > 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)