[jira] [Comment Edited] (ZOOKEEPER-4820) zookeeper pom leaks logback dependency
[ https://issues.apache.org/jira/browse/ZOOKEEPER-4820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Comment Edited] (ZOOKEEPER-4820) zookeeper pom leaks logback dependency
[ https://issues.apache.org/jira/browse/ZOOKEEPER-4820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831487#comment-17831487 ] Christopher Tubbs edited comment on ZOOKEEPER-4820 at 3/27/24 5:55 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. 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 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)
[jira] [Commented] (ZOOKEEPER-4820) zookeeper pom leaks logback dependency
[ https://issues.apache.org/jira/browse/ZOOKEEPER-4820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Comment Edited] (ZOOKEEPER-4820) zookeeper pom leaks logback dependency
[
https://issues.apache.org/jira/browse/ZOOKEEPER-4820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831484#comment-17831484
]
Christopher Tubbs edited comment on ZOOKEEPER-4820 at 3/27/24 5:45 PM:
---
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}
true
runtime
{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. This might happen if you use a
maven-assembly-plugin assembly descriptor that bundles dependencies, but omits
optional ones, for example. I'm not sure if the default behavior of
[includeDependencies|https://maven.apache.org/plugins/maven-assembly-plugin/assembly.html]
will include optional ones or not.
was (Author: ctubbsii):
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}
true
runtime
{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)
[jira] [Commented] (ZOOKEEPER-4820) zookeeper pom leaks logback dependency
[ https://issues.apache.org/jira/browse/ZOOKEEPER-4820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831485#comment-17831485 ] PJ Fanning commented on ZOOKEEPER-4820: --- or `provided` > 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)
[jira] [Commented] (ZOOKEEPER-4820) zookeeper pom leaks logback dependency
[
https://issues.apache.org/jira/browse/ZOOKEEPER-4820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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}
true
runtime
{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)
[jira] [Created] (ZOOKEEPER-4820) zookeeper pom leaks logback dependency
PJ Fanning created ZOOKEEPER-4820: - Summary: 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 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)
