Thanks for chasing this story Piotr. Let me see if I understand it right: * `log4j-slf4j-impl` has a `scope=runtime` dependency on `log4j-core` * This implies that `log4j-slf4j-impl`, next to bridging log4j-to-slf4j, uses Log4j for the backend * This implicit _"use of Log4j"_ was unintended, hence removed in 8f63620875 for `log4j-slf4j2-impl` * The idea was _"bridge should simply bridge, not impose a logger"_. * Yet users complain for two reasons: 1) the behavior is changed from `log4j-slf4j-impl` to `log4j-slf4j2-impl`, and 2) users' expectation were to indirectly get Log4j as the backend, though now they need to provide it explicitly
Assuming my observations are right, 1. I agree that we better add `log4j-core` as a runtime dependency to `log4j-slf4j2-impl` in `release-2.x` to match its behavior to `log4j-slf4j-impl`. 2. Regarding removing the `log4j-core` dependency from `log4j-slf4j[2]-impl` artifacts in `master`... I see where you are coming from and I agree this is _technically_ the right approach. That said, comments in LOG4J2-3601 clearly indicate that it is not intuitive for users. Put another way, users clearly indicate this was unexpected for them. I also think this is due to the fact that users still think _Log4j API is Log4j_, which is not true. I am inclined to gravitate from _the technically right approach_ to _the intuitive approach_: having `log4j-core` as a runtime dependency for `log4j-slf4j[2]-impl` artifacts. For one, this is what users ask for. Second, it implicitly onboards Log4j, which is good for us. Third, users can still opt-out via exclusion, if needed. On Fri, Dec 16, 2022 at 5:34 PM Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > > Hi, > > Since there is still some activity on LOG4J2-3601[#], I would propose to: > > * add `log4j-core` as runtime dependency of `log4j-slf4j2-impl` in 2.x, > * remove `log4j-core` from the runtime dependencies of `log4j-slf4j-impl` in > 3.x > > Do you have anything against it? > > Piotr > > [#] https://issues.apache.org/jira/browse/LOG4J2-3601
