Agreed with Ralph. I second the idea of dropping `log4j-1.2-api` from `3.0.0`.
On Mon, Apr 8, 2024 at 1:11 PM Apache <ralph.go...@dslextreme.com> wrote: > My opinion is to drop it from 3.0.0. 2.x is going to live a long time > still. By the time it dies Log4J 1.x will have been dead well over 15 > years, maybe even 20. That would give users plenty of time to be aware that > they need to plan to upgrade. > > Ralph > > > On Apr 8, 2024, at 3:35 AM, Piotr P. Karwasz <piotr.karw...@gmail.com> > wrote: > > > > Hi all, > > > > As you are probably aware, `log4j-1.2-api` is the second largest > > artifact we maintain. Yes, it is slightly larger than `log4j-api` and > > twice the size of JTL. > > > > This library is mainly used: > > > > 1. By some older frameworks/libraries that want to "help" users in > > their logging configuration. The amount of code that depends on > > `log4j-1.2-api` is usually measured in a dozen LoCs. > > 2. By some very old libraries that directly use Log4j 1.x for logging. > > I know a thing or two about Java archeology, but I couldn't give you a > > single example of such a library. The old legacy libraries I know > > mostly use JCL as a logging interface. > > > > Therefore I am wondering what should we do with this library in the > > upcoming 3.0.0 release: > > > > * should we drop it? The baseline of 3.0.0 is Java 17. Are there > > really applications that use Java 17 and at the same time use > > libraries that directly log to Log4j 1.x? > > * should we drop most of the code and move the two Log4j 1.x > > configuration factories to a new module? > > * should we just set an end-of-life date for the artifact and include > > it as it in Log4j 3.0.0? > > > > Piotr > > > > [1] https://github.com/apache/logging-log4j2/issues/2395 > >
