Experiment for (1): https://github.com/garydgregory/commons-logging/tree/log4j1-log42-api
Yes, I know there are test failures (they make sense, and that needs adjusting). Gary On Sat, Feb 10, 2024 at 11:26 AM 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
