[
https://issues.apache.org/jira/browse/ZOOKEEPER-4820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17831484#comment-17831484
]
Christopher Tubbs commented on ZOOKEEPER-4820:
----------------------------------------------
In case anybody wants to work on this, the right way to do this in Maven is to
mark the dependency optional in addition to making it runtime:
{code:xml}
<optional>true</optional>
<scope>runtime</scope>
{code}
However, you have to be careful if you use any build automation that changing
the dependency in this way doesn't cause it to be omitted from a distribution
assembly, like a .tar.gz, or .zip file.
> 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)
