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
