> On Feb 13, 2024, at 3:39 AM, Piotr P. Karwasz wrote:
>
> If such a thing is even possible, it would be nice if we can get
> `jakarta.logging` as the package prefix.
Creating a Jakarta logging would certainly be possible. I am not certain if
that follows the JCP process though since Jakart
Hi Gary,
On Sat, 10 Feb 2024 at 17:26, Gary Gregory wrote:
> 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
The only case in whic
Hi,
I agree with Piotr, except 3 there is no real point in any change IMHO so
think it is 3 for maintenance only or noop without any downside.
Le dim. 11 févr. 2024 à 00:35, Piotr P. Karwasz a
écrit :
> Hi Gary,
>
> On Sat, 10 Feb 2024 at 17:26, Gary Gregory wrote:
> > My main driver for the n
Hi Gary,
On Sat, 10 Feb 2024 at 17:26, Gary Gregory wrote:
> 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.
Log4JLogger is disabled by default in version 1.3.0 (cf. [1]) and the
dep
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 funct
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 wrote:
>
> Hi All:
>
> I want to focus on content before we decide what l
Below.
On Sat, Feb 10, 2024 at 12:11 PM sebb wrote:
>
> On Sat, 10 Feb 2024 at 16:27, Gary Gregory 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 Common
On Sat, 10 Feb 2024 at 16:27, Gary Gregory 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 su
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 JA
