Proposal: Experimental VEX File for Apache Commons Projects

2025-07-20 Thread Piotr P. Karwasz
Hi all, As you know, we released CVE-2025-48924 for Commons Lang a few days ago. Due to the widespread use of the library, the CVE has already triggered some user responses: for example, in [1], users reported being forced to upgrade Commons Lang and remove deprecated method usage due to inter

Re: [VOTE] Release Apache Commons IO 2.20.0 based on RC1

2025-07-18 Thread Piotr P. Karwasz
Hi Gary, W dniu 14.07.2025 o 23:36, Gary Gregory pisze: 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...

Re: [VOTE] Release Apache Commons Lang 3.18.0 based on RC2

2025-07-06 Thread Piotr P. Karwasz
Hi Gary, On 6.07.2025 19:51, Gary Gregory wrote: > 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...

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

2025-07-06 Thread Piotr P. Karwasz
Hi Gary, On 6.07.2025 14:16, Gary Gregory wrote: > 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...

Re: [VOTE] Release Apache Commons Lang 3.18.0 based on RC1

2025-07-06 Thread Piotr P. Karwasz
Hi Gary, On 5.07.2025 01:00, Gary Gregory wrote: > 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...

Re: (commons-parent) branch master updated: Exclude files from the Rat scan, that are generated by Eclipse.

2025-06-10 Thread Piotr P. Karwasz
Hi Gary, On Mon, Jun 9, 2025, 12:32 wrote: > Exclude files from the Rat scan, that are generated by Eclipse. On 9.06.2025 19:40, Gary Gregory wrote: > I've never needed this before and I use Eclipse as well. So I wonder why > you need it. Apache RAT excludes files listed in `.gitignore` by defau

Re: [VOTE] Release Apache Commons BeanUtils 1.11.0 based on RC1

2025-05-25 Thread Piotr P. Karwasz
Hi Gary, On 25.05.2025 21:09, Gary Gregory wrote: > On Sun, May 25, 2025 at 12:54 PM Piotr P. Karwasz >> It looks like the release candidate for Apache Commons BeanUtils >> 1.11.0 (RC1) was unintentionally removed in revision 77117. >> >> Fortunately, it's s

Re: [VOTE] Release Apache Commons BeanUtils 2.0.0-M2 based on RC1

2025-05-25 Thread Piotr P. Karwasz
Hi Gary, On 25.05.2025 16:18, Gary Gregory wrote: > Please review the release candidate and vote. > This vote will close no sooner than 24 hours from now. > > [ ] +1 Release these artifacts > [ ] +0 OK, but... > [ ] -0 OK, but really should fix... > [ ] -1 I oppose this release because...

Re: [VOTE] Release Apache Commons BeanUtils 1.11.0 based on RC1

2025-05-25 Thread Piotr P. Karwasz
Hi Gary, On 25.05.2025 at 15:27, Gary Gregory wrote: > Please review the release candidate and vote. > This vote will close no sooner than 24 hours from now. > > [ ] +1 Release these artifacts > [ ] +0 OK, but... > [ ] -0 OK, but really should fix... > [ ] -1 I oppose this release because.

Re: [VOTE] Release Apache Commons BeanUtils 1.11.0 based on RC1

2025-05-25 Thread Piotr P. Karwasz
Hi Gary, On 25.05.2025 15:27, Gary Gregory wrote: > Apache Commons BeanUtils 1.11.0 RC1 is available for review here: > https://dist.apache.org/repos/dist/dev/commons/beanutils/1.11.0-RC1 > (svn revision 77116) It looks like the release candidate for Apache Commons BeanUtils 1.11.0 (RC1) was

[FILEUPLOAD] 2.x: Less Might Be More

2025-05-23 Thread Piotr P. Karwasz
Hi all, Prompted by the recent vote on Commons FileUpload 2.0.0-M3, I'd like to share some thoughts on the evolving role of Commons FileUpload within the current Java ecosystem. As many of you know, Servlet 3.0—released in December 2009—introduced a file upload API[1] that closely mirrors Common

Re: [VOTE] Release Apache Commons JEXL 3.5.0 based on RC2

2025-04-13 Thread Piotr P. Karwasz
Hi Gary, On 12.04.2025 19:59, Gary Gregory wrote: 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... +1, release t

Re: [PR] 🏆 Add a Recommendation Badge from libs.tech [commons-imaging]

2025-03-28 Thread Piotr P. Karwasz
Hi Mark, On 26.03.2025 10:03, Mark Thomas wrote: On 26/03/2025 08:55, libstech-auto (via GitHub) wrote: This bot just earned themselves an ASF-wide ban from GitHub. The ban is not restricted to the ASF: on Wednesday I reported the user to GitHub and yesterday I received this response: On 2

Re: bundle symbolic name in source jars MANIFEST.MF file.

2025-03-18 Thread Piotr P. Karwasz
Hi Karaman, On 18.03.2025 10:47, Karaman, Mehmet wrote: Here is a short example of how the MANIFEST.MF has to look like: OSGi Modularity and Services - Tutorial. As I see that the Eclipse Orbit is repackaging the apache commons bundles with

Re: [VOTE] Release Apache Commons VFS Project 2.10.0 based on RC1

2025-02-14 Thread Piotr P. Karwasz
Hi Gary, On 13.02.2025 11:51, Piotr P. Karwasz wrote: Hi Gary, On 3.02.2025 00:26, Gary Gregory wrote: 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

Re: [VOTE] Release Apache Commons BeanUtils 1.10.1 based on RC1

2025-02-13 Thread Piotr P. Karwasz
Hi Gary, On 31.01.2025 16:34, Gary Gregory wrote: 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 che

Re: [VOTE] Release Apache Commons VFS Project 2.10.0 based on RC1

2025-02-13 Thread Piotr P. Karwasz
Hi Gary, On 3.02.2025 00:26, Gary Gregory wrote: 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... The ha

Re: [All] Useless update of "changes.xml"

2025-02-10 Thread Piotr P. Karwasz
Hi Arnout, On 10.02.2025 11:24, Arnout Engelen wrote: That doesn't seem easy to automate, though, and I'd say we don't want to add additional steps to the release process either. It is possible to automate (see [1] for example), but it requires a workflow to run as `pull-request-target`. Alte

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

2025-02-07 Thread Piotr P. Karwasz
Hi Gary, On 8.02.2025 00:35, Gary Gregory wrote: Nice find! :-) I fixed the offending files (zip and tar). Committed SVN revision 74783 (no longer revision 74565): After this change everything checks out: * hashes * signatures * build, test and reproducibility using: $ mvn -version Apache

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

2025-02-07 Thread Piotr P. Karwasz
Hi Gary, On 31.01.2025 16:38, Gary Gregory wrote: 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... The b

Re: [All] GSoC projet for Commons' web site(s) refactoring?

2025-01-22 Thread Piotr P. Karwasz
Hi Gilles, On 22.01.2025 12:51, Gilles Sadowski wrote: * Who would be willing to co-mentor the project? I can co-mentor the project. Piotr - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional comman

Re: [ALL] CRLF line endings causing problems

2025-01-21 Thread Piotr P. Karwasz
Hi Dávid, On 21.01.2025 18:44, Dávid Szigecsán wrote: I'm not 100% sure this is a valid concern at the moment, but I think it could be. You can add exceptions to a `.gitattribute` file. For example the `mvnw.cmd` file in Logging repos is configured to always have CRLF line endings[1]. Piot

Re: Using Git for websites

2025-01-19 Thread Piotr P. Karwasz
Hi Gilles, On 19.01.2025 17:42, Gilles Sadowski wrote: Le dim. 19 janv. 2025 à 15:06, Gary Gregory a écrit : This means writing documentation in Javadoc or Markdown which is now supported by the JDK. We could still consider Piotr's proposal (a general move to "Asciidoc"): https://asciidoct

Re: Using Git for websites

2025-01-19 Thread Piotr P. Karwasz
Hi Gilles, On 19.01.2025 14:30, Gilles Sadowski wrote: Hi. Le sam. 18 janv. 2025 à 19:14, Piotr P. Karwasz a écrit : The changes in `logging.apache.org` took close to 1000 work hours (2 developers for 3 months) and were financed by the Sovereign Tech Fund (now Agency). Commons has also

Re: Using Git for websites

2025-01-18 Thread Piotr P. Karwasz
Hi Gilles, On 18.01.2025 18:09, Gilles Sadowski wrote: Yes, it's likely a lot of work. Maybe a GSoC project (for which the candidate should somehow demonstrate the capacity to achieve the result _before_ being accepted, so that we don't end up doing twice as much work...)? The changes in `logg

Re: [ALL] CRLF line endings causing problems

2025-01-18 Thread Piotr P. Karwasz
Hi Alex, On 18.01.2025 18:06, Alex Herbert wrote: $ echo "* text=auto" >>.gitattributes $ rm .git/index # Remove the index to force Git to $ git reset # re-scan the working directory $ git status# Show files that will be normalized $ git add -u $ git add .gitattributes $ git

Re: [ALL] CRLF line endings causing problems

2025-01-18 Thread Piotr P. Karwasz
Hi Gary, On 18.01.2025 18:11, Gary Gregory wrote: Do you need this in each active branch? Does it work with PRs? Yes, I am afraid you need it in all the active branches. It works with PRs, since basically it converts CRLF to LF each time you call `git add`. Piotr

Re: [ALL] CRLF line endings causing problems

2025-01-18 Thread Piotr P. Karwasz
Hi sebb, On 18.01.2025 16:46, sebb wrote: On Sat, 18 Jan 2025 at 15:35, sebb wrote: Ideally we need something that is part of the repo checkout. Has anyone experience of using .gitattributes? That looks as though it might be a solution. We are using `.gitattributes` in all Log4j repos with

Re: [ALL] Reproducible builds

2025-01-12 Thread Piotr P. Karwasz
Hi Gary, On 12.01.2025 13:40, Gary Gregory wrote: [ERROR] sha512 mismatch commons-cli-1.10.0.spdx.json: investigate with diffoscope target/reference/commons-cli/commons-cli-1.10.0.spdx.json target/site/commons-cli_commons-cli-1.10.0.spdx.json [ERROR] Reproducible Build output summary: 7 files ok

Re: [ALL] Reproducible builds

2025-01-11 Thread Piotr P. Karwasz
Hi Gary, On 11.01.2025 15:59, Gary Gregory wrote: In a vote thread, Herve wrote: " install should seriously be avoided when voting, but verify or package And with mvn clean verify site -s "$HOME/.m2/commons-settings.xml" artifact:compare -Dreference.repo=https://repository.apache.org/content/r

Re: [VOTE] Release Apache Commons CSV 1.13.0 based on RC1

2025-01-10 Thread Piotr P. Karwasz
Hi, On 10.01.2025 00:04, Herve Boutemy wrote: -0 as I feared, same issue as Commons Release Plugin 1.9.0 RC1: wrong component hash in SBOM (in this case, it's one dependency: commons-codec) -0 Same problem: the SBOMs are not reproducible. I also wonder if we really need to publish the `tes

Re: [DISCUSS][VOTE] Release Apache Commons CSV 1.13.0 based on RC1

2025-01-10 Thread Piotr P. Karwasz
Hi sebb, On 10.01.2025 00:56, sebb wrote: On Thu, 9 Jan 2025 at 23:04, Herve Boutemy wrote: When I read Built using: mvn clean install site -s "$HOME/.m2/commons-settings.xml" install should seriously be avoided when voting, but verify or package Are you sure install is not needed with mult

Re: [VOTE] Release Apache Commons Collections 4.5.0-M3 based on RC1

2024-12-15 Thread Piotr P. Karwasz
Hi Gary, On 15.12.2024 16:46, Gary Gregory wrote: 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... * The

Re: Subject: Proposal: Standardizing String Concatenation in Apache Commons

2024-12-14 Thread Piotr P. Karwasz
Hi Gary, On 14.12.2024 17:45, Gary Gregory wrote: What passes the criteria of "simple cases"? I would classify all sequences of `new StringBuilder()`, `append` and `toString` without any branching or loops as simple cases. Should this be enforced or can it be enforced? With Checkstyle? Som

Re: Subject: Proposal: Standardizing String Concatenation in Apache Commons

2024-12-14 Thread Piotr P. Karwasz
Hi Serw, On 13.12.2024 22:08, Serw wrote: Would the community support using string concatenation over StringBuilder for simple cases? Modern JDKs (8+) optimize string concatenation efficiently, making it both concise and performant. Since the Javac compiler replaces string concatenation with

Re: [LANG] [DISCUSS] Java Modularity support in commons-lang3

2024-12-14 Thread Piotr P. Karwasz
Hi Mark, On 9.12.2024 17:37, Mark Struberg wrote: c) try using this on a class which contains e.g. an ArrayList, a Set or a Map. It will e.g. use List#equals() which also does equals() on it's items (btw, I explained this to you already...). Which is NOT what users expect. Instead it should i

Re: [LANG] Normalizing StringUtils output

2024-12-04 Thread Piotr P. Karwasz
Hi Gary, On 4.12.2024 12:44, Gary Gregory wrote: The StringUtils methods return a mix of null and "" for each method on null input. Each method does one of the following: - null out for null in - "" out for null in - null for null and "" for "" - throw an NPE We definitively need to put some

Re: [LANG] RuntimeEnvironment class

2024-12-01 Thread Piotr P. Karwasz
Hi sebb, On 1.12.2024 12:27, sebb wrote: It's not clear to me that this belongs in LANG. I tend to agree with you. Since the purpose of containers is to run applications the same way they would run on the host system, I don't believe this method belongs to any Java library. Unfortunately s

Re: [VOTE] Release Apache Commons DBCP 2.13.0 based on RC1

2024-11-27 Thread Piotr P. Karwasz
Hi Gary, On 23.11.2024 23:47, Gary Gregory wrote: 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... +1 -

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

2024-11-22 Thread Piotr P. Karwasz
Hi Gary, On 22.11.2024 18:26, Gary Gregory wrote: The point of the Log4j update and the release is to show that version of Log4j is formally tested and supported. This removes any guessing game for users. I totally understand the spirit of providing a list of the most recent compatible depen

[DISCUSS][VOTE] Release Apache Commons Logging 1.3.5 based on RC1

2024-11-22 Thread Piotr P. Karwasz
Hi Gary, On 22.11.2024 16:58, Gary Gregory wrote: We have bumped the Log4j dependency and done some light housekeeping since Apache Commons Logging 1.3.4 was released, so I would like to release Apache Commons Logging 1.3.5. Sorry, but I really don't see the point of this release. Log4j API is

Re: (commons-validator) 08/11: Removed unnecessary lambdas in the tests

2024-11-19 Thread Piotr P. Karwasz
Hi Gary, On 18.11.2024 17:11, Gary Gregory wrote: -1 you are undoing the port to JUnit 5. This commit is a classic JUnit mistake imo, please stop, these JUnit APIs exist for a reason: The lambdas avoid construction of failure message strings, which, as a pattern, add processing, can have side ef

Re: (commons-compress) branch master updated: Replace org.apache.commons.io.Charsets with org.apache.commons.compress.utils.Charsets

2024-11-18 Thread Piotr P. Karwasz
Hi Gilles, On 16.11.2024 16:11, Gilles Sadowski wrote: Both sides have something in their favour; you are right in the short term, Gary is right in the longer term. [IMO] Wouldn't the project benefit from a common policy on how to deal with such issues (rather than be divisive, once more)? [I'd

Re: (commons-compress) branch master updated: Replace org.apache.commons.io.Charsets with org.apache.commons.compress.utils.Charsets

2024-11-16 Thread Piotr P. Karwasz
Hi all, On 16.11.2024 14:45, Emmanuel Bourg wrote: I don't understand your stubbornness on this subject, Commons Compress had zero dependencies for over 10 years, the general sentiment from the recent discussions seems to point toward avoiding such a dependency bloat, your change was never dis

Re: (commons-compress) Modularization?

2024-11-04 Thread Piotr P. Karwasz
Gary, On 4.11.2024 19:36, Gary Gregory wrote: If you modularize, then put pack200 in a module... the reason it's there is because some apps broke when Java removed the functionality. Sure, I can do it, but one of the opportunities of a major release is to remove the code that is outdated and

Re: (commons-compress) Modularization?

2024-11-04 Thread Piotr P. Karwasz
Hi Emmanuel, On 4.11.2024 09:27, Emmanuel Bourg wrote: Le 02/11/2024 à 13:19, Gilles Sadowski a écrit : My question was and still is:  Can modularization help? Modularization is very much needed for Commons Compress, I think we should at least split the compression part from the archive par

Re: Please welcome Piotr Karwasz as a committer

2024-08-27 Thread Piotr P. Karwasz
Hi Gary, On Tue, 27 Aug 2024 at 15:14, Gary Gregory wrote: > Please welcome Piotr Karwasz as a committer. Thank You for the invite. > Piotr (Apache ID ppkarwasz) is no stranger to those of us also > involved with Apache Logging's Log4j component :-) > > Piotr: Please subscribe to our mailing li

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 > > https://dist.apache.org/repos/dist/dev/commons/logging/1.3.2-RC2/site/changes-

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 `r

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 L

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 descript

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 arti

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 compatib

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 that

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 class

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. The

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 op

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 whic

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 dep

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 we

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 -Dmaven.javadoc.ski

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 > │ @@ -65,1

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. I

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: [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 > they'

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 te