I'm fine with #1 or #2 if you can make either work. I actively dislike #3. In particular I do not think we should change package names or Maven coordinates. I think it is OK and in this case highly advisable to break API compatibility solely by removing support for obsolete and mostly unused functionality. It is much more important to keep the API for the actively and widely used API intact. That includes package names and Maven coordinates. Changing these makes upgrading to the newer version far more burdensome. Many projects won't do it, and most won't do it quickly.
#4 strikes me as excessively nit-picky. If you're going to turn all methods into no-ops, you might as well remove the API. At least then clients of these APIs know their code is broken. Log4J 1.x is not the only thing we need to cut out. We also need to remove AvalonLogger and Jdk13LumberjackLogger, but if you can remove log4j 1.x in commons-logging 1.4 without breaking things that's a step in the right direction. Otherwise, I propose dropping AvalonLogger, Jdk13LumberjackLogger, and Log4jLogger; and shipping what's left as 2.0. On Sat, Feb 10, 2024 at 4:27 PM Gary Gregory <garydgreg...@gmail.com> wrote: > > Hi All: > > I want to focus on content before we decide what label to put on the > next release. Then, we can see if we want to break binary > compatibility (BC) for a Commons Logging 2.0.0. > > My main driver for the next version is to drop support and dependency > on the Log4j 1.x JARs file(s). I speak of JAR files here as opposed to > APIs, see below. > > I see several ways to drop Log4j 1.x JARs. > 1) Replace the dependency on Log4j 1.x with the Log4j 2 compatibility > JAR for 1.2: org.apache.logging.log4j:log4j-1.2-api > This maintains BC and can become 1.4.0. > 2) A re-implementation of Log4JLogger where all methods call Log4j 2 APIs. > This maintains BC and can become 1.4.0. > It looks like this is not possible in a straightforward manner > because we have Log4j 1 classes in the public API, specifically > org.apache.commons.logging.impl.Log4JLogger.Log4JLogger(Logger). It > might not be worth hacking around that if that's even possible. > 3) A hard delete of org.apache.commons.logging.impl.Log4JLogger (the > class is deprecated in 1.3.0 FWIW). > This breaks BC and requires a 2.0.0 with a package name and Maven > coordinate change. > The package would change from org.apache.commons.logging to > org.apache.commons.logging2. > The Maven coordinates would change from > commons-logging:commons-logging to org.apache.commons:commons-logging2 > 4) A gutting of Log4JLogger where all methods are no-ops. > This maintains BC and can become 1.4.0. > > I like (1) the best, it gives us a clear path to a 1.4.0 without > breaking BC and removes dependencies on the 1.x jars. > From my POV breaking BC in Logging 1.x is a non-starter. > > Then, if we want to remove support for the Log4j 1 API (the JAR is > already gone at this point), that would necessitate a 2.0.0. > > Gary > > On Sat, Feb 10, 2024 at 8:53 AM Elliotte Rusty Harold > <elh...@ibiblio.org> wrote: > > > > I'd like to plan and start working on a 2.0 release of commons-logging > > with the specific goal of resolving the large number of out of date, > > unsupported, old libraries that this project pulls into so many > > dependency trees. There's been some discussion of a 2.0 release in > > JIra at https://issues.apache.org/jira/projects/LOGGING/issues/LOGGING-187 > > but I'd lik to bring this to a wider audience. Specifically my > > thoughts are: > > > > 1. 2.0 will be technically API incompatible since it will remove all > > traces of EOL libraries like log4j 1.x and avalon. > > 2. It will otherwise be a drop-in replacement for anyone not using > > these old libraries. Specifically: > > * Other deprecated methods are not removed. > > * The package name does not change. > > * The group ID and artifact ID do not change. > > * Minimum Java version remains 1.8 > > 3. It can include any recent, API compatible bug fixes and new > > features that are available at HEAD, but these are not blockers. > > > > While there are other more incompatible changes that could be made in > > a major version bump, I think it's really important to produce a > > drop-in replacement that is friendlier to security scanners and > > dependency analyzers. I do not want to discourage people from > > upgrading for any reason other than they're still using EOL libraries > > like log4j 1.x. > > > > 1.3.0 was recently released and seems up to date with the last several > > years of changes and bugs, so it feels like a good time to make the > > break. Anyone who isn't ready to give up their decade+ old loggers can > > stay on this release for a while. However if there's a strong need to > > maintain a 1.x branch that could be done too. Or we could start 2.x > > as a separate branch. > > > > If this achieves rough consensus, I can start sending PRs. However, > > the final release would require a commons committer or perhaps PMC > > member to take over. > > > > Thoughts? > > > > -- > > Elliotte Rusty Harold > > elh...@ibiblio.org > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Elliotte Rusty Harold elh...@ibiblio.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
