[
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)
