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
