This all sounds very confusing to me. Using this scheme, I could create a set of dependencies on 2.x with empty jars that don't work on 3.x (because I picked the wrong jars). There is no way to verify that what I'm doing on 2.x will work on 3.x without trying it on 3.x, so... or am I missing something?
Gary On Sun, Jan 19, 2025 at 1:32 PM Piotr P. Karwasz <pi...@mailing.copernik.eu> wrote: > > Hi Robert, > > On 19.01.2025 18:39, Robert Middleton wrote: > > If I'm understanding this correctly, this sounds like a bad idea. > > While it does make the 2.x -> 3.x transition easier, it creates a > > bigger issue for when you go from 2.x -> 2.y. > > As long as `x` is higher than `y` there will be no problems: the > additional artifacts are not necessary in 2.x, they are just semantic > sugar. Users can still add the third-party dependencies like > `com.lmax:disruptor` themselves, but they could also just add > `log4j-async-logger` and let us choose the appropriate `disruptor` > version to use. > > The additional artifacts are also meant to help solving security alerts. > Imagine a CVE is published against XZ that affects the decompression of > archives. The developer of Acme Cool Server: > > 1. Finds out that `xz` is a transitive dependency of his app. > > 2. Finds out that `xz` is pulled by the direct dependency > `commons-compress`. > > 3. Asks the Commons project if the problem in `xz` can affect > `commons-compress`. > > 4. The answer will probably be "if you use decompression, YES" and he > will need to dive into the code to see how Commons Compress is used. > > 5. He won't find anything in its own code and he will spend several > hours to find out the Commons Compress is used by `log4j-core`. > > 6. Asks us if the problem in `xz` can affect `log4j-core`. > > 7. We will answer "NO, the affected code is not reachable". > > If we introduce a `log4j-compress` artifact that depends on > `commons-compress` and the application uses it, steps 3-5 can be skipped. > > Piotr >
