Below. On Sat, Feb 10, 2024 at 12:11 PM sebb <seb...@gmail.com> wrote: > > On Sat, 10 Feb 2024 at 16:27, 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. > > Isn't that much the same as re-implementing option 1?
Of course, but it would be the direct path. > > > 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. > > Surely it would be better to throw an Exception rather than > silently drop what could be important info? That's option 5) ;-) if it's OK to blow up apps ;-) Gary > > > 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 > > > > --------------------------------------------------------------------- > 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
