Re: [LOGGING] 2.0

2024-02-13 Thread Piotr P. Karwasz
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

Re: [LOGGING] 2.0

2024-02-10 Thread Piotr P. Karwasz
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

Reproducibility of Commons artifacts was: [VOTE] Release Apache Commons Logging 1.3.0 based on RC1

2023-12-16 Thread Piotr P. Karwasz
Hi all, On Mon, 27 Nov 2023 at 00:15, Piotr P. Karwasz wrote: > 2. For some strange reason I had to set `TZ=America/New_York` to make > the main JAR reproducible. Either the Moditect or the Maven JAR plugin > are responsible for that. The recent Commons artifacts are hard to reprodu

Re: Reproducibility of Commons artifacts was: [VOTE] Release Apache Commons Logging 1.3.0 based on RC1

2023-12-28 Thread Piotr P. Karwasz
Hi Gary, On Thu, 28 Dec 2023 at 16:03, Gary Gregory wrote: > What value for $NEXUS_REPO would one use to verify repro _after_ a > release? I want to experiment with Apache Commons components... The `reference.repo` system variable is used by the `referenceRepo` parameter of `artifact:compare`:

Re: [ALL] Deploying SNAPSHOTS from GH workflows

2023-12-20 Thread Piotr P. Karwasz
Hi Gary, On Wed, 20 Dec 2023 at 14:57, Gary Gregory wrote: > > Also FYI, over at Log4j, we (Volkan and Piotr are the drivers) have been > creating releases from GitHub. I'm not sure we need to go this far here, > but there might be tidbits there that may prove useful. Thanks for mentioning it.

Re: Reproducibility of Commons artifacts was: [VOTE] Release Apache Commons Logging 1.3.0 based on RC1

2023-12-29 Thread Piotr P. Karwasz
Hi Gary, On Fri, 29 Dec 2023 at 13:37, Gary Gregory wrote: > I do appreciate the fact that I can ask "Am I reproducible" but the > output is... cryptic. Yes, unfortunately if the check fails, finding the reason of the failure is hard. > For example: > ... > ├── META-INF/MANIFEST.MF > │ @@

Re: Reproducibility of Commons artifacts was: [VOTE] Release Apache Commons Logging 1.3.0 based on RC1

2023-12-29 Thread Piotr P. Karwasz
Hi Gary, On Fri, 29 Dec 2023 at 15:11, Gary Gregory wrote: > I run, copied from the > https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/org/apache/commons/compress/commons-compress-1.25.0.buildspec: > > mvn -Prelease clean package package -DskipTests

Re: Reproducibility of Commons artifacts was: [VOTE] Release Apache Commons Logging 1.3.0 based on RC1

2024-01-05 Thread Piotr P. Karwasz
Hi Hervé, On Fri, 5 Jan 2024 at 08:14, Herve Boutemy wrote: > Piotr found the issue about the second run of bundle plugin and about > moditect 1.1.0 sensitivity to TZ: I don't know how hard it was to learn this, > nor how. > Do you have any idea on how to ease such discovery? The first time

Re: [VOTE] Release Apache Commons Logging 1.3.0 based on RC1

2023-11-26 Thread Piotr P. Karwasz
Hi Gary, > Please review the release candidate and vote. > This vote will close no sooner than 72 hours from now. > > [ ] +1 Release these artifacts > [ ] +0 OK, but... > [ ] -0 OK, but really should fix... > [ ] -1 I oppose this release because... I performed the following tests: * I

Re: [VOTE] Release Apache Commons Validator 1.8.0 based on RC1

2023-12-03 Thread Piotr P. Karwasz
Hi Elliotte, On Sun, 3 Dec 2023 at 14:13, Elliotte Rusty Harold wrote: > > https://issues.apache.org/jira/projects/VALIDATOR/issues/VALIDATOR-390 > and https://issues.apache.org/jira/projects/VALIDATOR/issues/VALIDATOR-357 > are both open dependency upgrades with security implications. If >

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

2024-02-27 Thread Piotr P. Karwasz
Hi Gary, On Thu, 22 Feb 2024 at 17:14, Gary Gregory wrote: > What I've been going in some projects is to never use Maven optional > dependencies and split Maven projects into multi-module ones and never use > optional dependencies when I care about what depends on what. I totally agree. Maven

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

2024-02-27 Thread Piotr P. Karwasz
Hi Elliotte, On Tue, 27 Feb 2024 at 13:20, Elliotte Rusty Harold wrote: > > On Tue, Feb 27, 2024 at 8:27 AM Piotr P. Karwasz > wrote: > e will not be loaded even if it is available. > > > > Fortunately Commons Compress is well-engineered and easy to split. T

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

2024-02-28 Thread Piotr P. Karwasz
Hi Romain, On Wed, 28 Feb 2024 at 16:30, Romain Manni-Bucau wrote: > > Hmm, splitting will require a package change at least for osgi. OSGi should be painless: the common practice is to use `Import-Package` instead of `Require-Bundle`, this way it is up to the OSGi environment to figure out

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

2024-02-28 Thread Piotr P. Karwasz
Hi Elliotte, On Wed, 28 Feb 2024 at 13:44, Elliotte Rusty Harold wrote: > I'm not quite sure what you're proposing. This works if you also > change the package to something like org.apache.commons.compress2. It > does not work without changing the package names. The bottom line is: > > 1. A

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

2024-02-28 Thread Piotr P. Karwasz
Hi sebb, On Wed, 28 Feb 2024 at 23:48, sebb wrote: > > Remark that I am talking about moving whole packages to new artifacts. > > Will these packages be renamed? > > If not, then I don't see how you can prevent possible class duplication. Do they need to be renamed? This breaks backward

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

2024-02-29 Thread Piotr P. Karwasz
Hi sebb, On Thu, 29 Feb 2024 at 10:25, sebb wrote: > > but dependency management can be used to > > prevent version mismatches. > > What dependency management is that? Does Maven manage this? > Seems like users would be forced to use extra controls to ensure only > comaptible combinations of

Re: [VOTE] Release Apache Commons Logging 1.4.0 based on RC1

2024-03-17 Thread Piotr P. Karwasz
Hi Gary, On Sun, 17 Mar 2024 at 13:45, Gary Gregory wrote: > For example? The Logback PR requires Java 11. What else? Logkit? Maybe but > I've never heard anyone ask for that. The two OSGi PRs are important: * https://github.com/apache/commons-logging/pull/188: fixes a typo in the OSGi

Re: Is there a blog for commons?

2024-04-19 Thread Piotr P. Karwasz
Hi Bruno, On Fri, 19 Apr 2024 at 13:30, Bruno Kinoshita wrote: > Maybe an option would be to just have it under > https://commons.apache.org/blog/, as part of the project website in Git, > published with the site manually/ASF CRM/etc? I think that way INFRA would > not have to be involved? The

Re: [ALL] GitHub is done with Java 8

2024-04-29 Thread Piotr P. Karwasz
Hi Gary, On Mon, 29 Apr 2024 at 13:58, Gary Gregory wrote: > To resolve this issue in the least disruptive manner, I updated builds > that need Java 8 AND macOS from "macos-lateset" to "macos-13". In Log4j I updated all builds that require Java 8 + another JDK to use `zulu` as distribution if

Re: [VOTE] Release Apache Commons Logging 1.3.2 based on RC2

2024-05-11 Thread Piotr P. Karwasz
Hi Gary, On Sat, 11 May 2024 at 19:55, Gary Gregory wrote: > Details of changes since 1.3.1 are in the release notes: > > https://dist.apache.org/repos/dist/dev/commons/logging/1.3.2-RC2/RELEASE-NOTES.txt > >