Hi Ralph,
On 19.01.2025 17:55, Ralph Goers wrote:
I must be misunderstanding. IIUC you are proposing that to eliminate optional
dependencies we create a bunch of empty jars, presumably with a pom that has
the dependency as required. How exactly does that help? Doesn’t that new,
empty artifact just become an optional dependency? Isn’t it required during the
build to allow the dependency to be resolved?
As you remark, the optional dependencies in `log4j-core` must remain (at
least at compile time, so they must be either `provided` or
`compile+optional` like now). What I am proposing is to create a new
`log4j-async-logger` artifact with a non-optional dependency on
`com.lmax:disruptor`. We should then change the installation
documentation for async loggers[1] and ask users to add:
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-async-logger</artifactId>
<scope>runtime</scope>
</dependency>
The advantage of such a change is that:
* It makes the upgrade to Log4j Core 3 trivial (the same dependency is
required in Log4j Core 3[2])
* Users no longer have to remember what `disruptor` is and why they
added it to their application. They will upgrade the version of
`disruptor` each time we upgrade it.
Gradle has a special way to treat optional dependencies[3], this
proposal is the closest Maven-equivalent I could find.
Piotr
[1] https://logging.apache.org/log4j/2.x/manual/async.html#installation
[2] https://logging.apache.org/log4j/2.x/manual/async.html#installation
[3] https://blog.gradle.org/optional-dependencies
