[
https://issues.apache.org/jira/browse/ZOOKEEPER-4820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17831487#comment-17831487
]
Christopher Tubbs edited comment on ZOOKEEPER-4820 at 3/27/24 5:57 PM:
-----------------------------------------------------------------------
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 understand that this may 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.
For what it's worth, I think provided dependencies will be excluded by the
maven-assembly-plugin, which is not what you want (but may not matter if the
plugin is declared explicitly in the assembly descriptor). I'd stick with
optional if it works.
was (Author: ctubbsii):
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 understand that this may 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)
