[
https://issues.apache.org/jira/browse/LOG4J2-3601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17607343#comment-17607343
]
Christopher Tubbs commented on LOG4J2-3601:
-------------------------------------------
Yes, technically, for maximum user choice, it could be considered a bug "that
log4j-slf4j-impl has a runtime dependency on log4j-core when it should not",
rather than log4j-slf4j2-impl failing to have a runtime dependency on it.
However, that completely ignores how users actually use intend to use this
bridge in real life. The *whole point* of a user selecting these bridges is
that users want to use log4j-core at runtime. This bridge should be enough get
us there.
It makes no sense to merely use these bridges to get us to log4j-api, and then
we have to separately make the decision to use log4j-core explicitly, because
nobody would do that. If we wanted a runtime other than log4j-core, we wouldn't
use these bridges at all.... we would use the slf4j bridge that takes us
directly to the desired runtime. We only use this bridge because we want to be
taken directly to log4j-core. The runtime dependency on log4j-core is the
desired outcome. It works fine with slf4j 1.7 and log4j-slf4j-impl, and it
should work the same (with a runtime dependency on log4j-core) with slf4j 2 and
log4j-sfl4j2-impl.
You could decide to make log4j-slf4j-impl have a test dependency on log4j-core
instead of fixing log4j-slf4j2-impl to have a runtime dependency on it... but
then you're just making things harder on users, and you're inviting more bug
reports like this one, but against the log4j-slf4j-impl jar for slf4j 1.7 uses
as well.
As for [~rgoers] idea about a "default dependency"... I think the concept is
neat, but ultimately, I don't think it's necessary... at least not for Maven.
You can always "exclude" a transitive dependency and replace it with a
different one. So, the "default dependency" is just a regular old dependency.
If users really wanted to use this bridge to redirect to log4j-api, with a
different runtime, they could exclude the runtime dependency on log4j-core and
add their own pretty easily. However, as I've stated multiple times, that's not
sensible... because any desired runtime would likely already have a direct
bridge from slf4j, so they would just use that instead of using this bridge at
all.
> log4j-slf4j2: change of dependency scope for log4j-core
> -------------------------------------------------------
>
> Key: LOG4J2-3601
> URL: https://issues.apache.org/jira/browse/LOG4J2-3601
> Project: Log4j 2
> Issue Type: Improvement
> Components: SLF4J Bridge
> Affects Versions: 2.19.0
> Reporter: Andy Seaborne
> Priority: Major
>
> The artifact {{log4j-slf4j-impl}} has a scope=runtime dependency on
> log4j-core. {{log4j-slf4j18-impl}} similarly had scope=runtime.
> The artifact {{log4j-slf4j2-impl}} has a scope=test dependency on log4j-core.
> This changed as part of [commit
> 8f63620875|https://github.com/apache/logging-log4j2/pull/1024/files#diff-d3ba9956a9f81420d0be3d69477a05b505746272d548ab17404aa47f3e5946b0]
> although it seems to be unrelated.
> It makes switching over more of a bump. Previously just depending on
> {{log4j-slf4j-impl}} was enough.
> Please switch back to a scope=runtime dependency for {{log4j-slf4j2-impl}}.
> Example: we (Apache Jena) use slf4j in the main code base, and select log4j
> when it needed for binaries tests so we have multiple places where the
> dependency happens. We can change - but this may be a user experience for
> others as well.
> {noformat}
> [INFO] +- org.apache.logging.log4j:log4j-slf4j-impl:jar:2.18.0:compile
> [INFO] | +- org.apache.logging.log4j:log4j-api:jar:2.18.0:compile
> [INFO] | \- org.apache.logging.log4j:log4j-core:jar:2.18.0:runtime
> {noformat}
> {noformat}
> [INFO] +- org.apache.logging.log4j:log4j-slf4j2-impl:jar:2.19.0:compile
> [INFO] | \- org.apache.logging.log4j:log4j-api:jar:2.19.0:compile
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
