You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by "Piotr P. Karwasz" <pi...@mailing.copernik.eu> on 2025/07/05 21:08:39 UTC
[VOTE] Release Apache Log4j `2.25.1` (RC1)
This is a vote to release the Apache Log4j `2.25.1`.
Website: https://logging.staged.apache.org/log4j/2.25.1/index.html
GitHub: https://github.com/apache/logging-log4j2
Commit: bda63362cf405449ff4edc2e4d92353be65c4d4e
Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j/2.25.1
Nexus:
https://repository.apache.org:443/content/repositories/orgapachelogging-1320
Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0
Review kit:
https://logging.apache.org/logging-parent/release-review-instructions.html[*]
Please download, test, and cast your votes on this mailing list.
You can optionally also cast your vote in the ATR system[**].
[ ] +1, release the artifacts
[ ] -1, don't release, because...
This vote is open for 72 hours and will pass unless getting a
net negative vote count. All votes are welcome and we encourage
everyone to test the release, but only the Logging Services PMC
votes are officially counted. At least 3 +1 votes and more
positive than negative votes are required.
[*] As with the 2.25.0 release, the aggregate SBOM for the log4j-bom
artifact in version 2.25.1 is not fully reproducible. Two variants may
be generated that differ only in the ordering of the `jspecify` dependency.
This issue is known and tracked under GitHub issue #3804:
https://github.com/apache/logging-log4j2/issues/3804
To avoid false negatives during verification, reviewers are asked to
ignore this specific difference by appending the following parameter to
the build command in the release review instructions:
-Dbuildinfo.ignore="*/log4j-bom-2.25.1-cyclonedx.xml"
[**] Please note that the Apache Trusted Release (ATR) tool is currently
in alpha, and votes cast through ATR are not officially counted in the
release process. However, Apache committers are encouraged to try it out
and provide feedback using the following URL:
https://release-test.apache.org/vote/logging-log4j/2.25.1
== Release Notes
This patch release addresses a dozen bugs in version `2.25.0`, in
particular:
* Resolves a concurrency issue in the new unified datetime formatter.
* Fixes build failures affecting Gradle users.
* Restores backward compatibility with Spring Boot’s common logging
configuration.
* Improves handling of edge cases in GraalVM support.
The complete changelog of the `2.25.1` release can be found on the
staged website at:
https://logging.staged.apache.org/log4j/2.25.1/release-notes.html#release-notes-2-25-1
Re: Release notes, changelog and commits
Posted by "Piotr P. Karwasz" <pi...@mailing.copernik.eu>.
Hi all,
On 8.07.2025 17:10, Piotr P. Karwasz wrote:
> 3. **Commits**
>
> GitHub/Dependabot uses the three-dot comparison between release tags, e.g.:
>
> https://github.com/apache/logging-log4j2/compare/rel%2F2.24.3...rel%2F2.25.0
>
> Due to the way I’ve been creating patch releases—by branching off the
> previous release tag and cherry-picking fixes from `2.x`—the merge base
> between patch and minor releases is often far back, usually before the
> previous minor.
>
> As a result, the commit list in these comparisons includes too many
> unrelated changes. This might be worth revisiting. Should we consider a
> different strategy for patch releases to improve clarity in these diffs?
I think we can address this by temporarily maintaining two branches
after each minor release:
- Merge PRs with features and other API changes into `2.x`.
- Merge PRs with only bug fixes into a `2.25.x` branch (or equivalent).
We would only keep the extra branch for a short time after a minor
release. Once the next minor is close to release, we can merge `2.25.x`
back into `2.x` and delete it.
With this approach, a `git log rel/2.25.y..rel/2.26.0` would contain:
- New features added since the `rel/2.25.0` branch point.
- Any unreleased bug fixes from the last `2.25.y` patch up to the merge
back into `2.x`.
This should make GitHub’s tag-to-tag comparisons much clearer.
What do you think?
Piotr
Release notes, changelog and commits
Posted by "Piotr P. Karwasz" <pi...@mailing.copernik.eu>.
Hi Volkan,
On 8.07.2025 10:44, Volkan Yazıcı wrote:
> I see that the most recent VOTE email misses ticket IDs, making it
> cumbersome to access associated PRs. I can see the Discussion linked, but
> that is not what I am asking for.
>
> Can we share the Issue/PR IDs in the VOTE emails, please?
I appreciate you bringing this up. Since you find it helpful, and I have
no strong objections, I will include the changelog in future VOTE emails.
That said, I’d like to use this opportunity to open a broader discussion
on how we handle and duplicate release-related content across various
channels. Specifically, I’d like to clarify our approach regarding the
following:
1. **Release Notes**
These are the curated summaries we write in `.release-notes.adoc.ftl`
files. In my view, release notes are essential and should appear in all
of the following:
* Our website.
* The VOTE email (so PMC members can easily see what changed).
* The `announce@apache.org` email (while not universally practiced, many
projects include release notes in the announcement [3]).
* GitHub Releases, since Dependabot pulls release notes from there.
While some projects (e.g., JUnit) only link to their website in their
GitHub Releases, I believe inlining our release notes is worthwhile.
Note that—except for our website, which uses the original AsciiDoc
format—all other channels require manual conversion to plain text or
Markdown, particularly for hyperlinks.
2. **Changelog**
By *changelog*, I mean a complete list of changes relevant to
users—excluding things like test or Javadoc updates, which don’t affect
user-facing behavior.
I suggest we **do not** replicate the changelog in too many places. Instead:
* Keep it on the website.
* Include it in the VOTE email (useful for developers, even if a bit noisy).
* Link to it in the announcement email, rather than embedding it.
For GitHub/Dependabot purposes, we have two options:
1. Add a link to the website in our GitHub Releases.
2. Add a `CHANGELOG.md` file in the repo with the latest entries, and
link to the website for older ones.
GitHub looks for keywords like `changelog`, `news`, `changes`,
`history`, etc., to identify changelog files.
3. **Commits**
GitHub/Dependabot uses the three-dot comparison between release tags, e.g.:
https://github.com/apache/logging-log4j2/compare/rel%2F2.24.3...rel%2F2.25.0
Due to the way I’ve been creating patch releases—by branching off the
previous release tag and cherry-picking fixes from `2.x`—the merge base
between patch and minor releases is often far back, usually before the
previous minor.
As a result, the commit list in these comparisons includes too many
unrelated changes. This might be worth revisiting. Should we consider a
different strategy for patch releases to improve clarity in these diffs?
**Context and Motivation**
I’ve been working on enhancing `dependabot/fetch-metadata` to use it in
our Dependabot workflow, which led me to explore how release information
is generated by the bot. To help users decide whether a dependency
update is relevant (e.g., for a Log4j patch), we should aim to expose
structured and clear metadata.
For a quick preview on what data Dependabot gathers, see
ppkarwasz/logging-log4j2#566[2]. The sources of the gathered data are:
1. For the "Release notes" section: GitHub Releases.
2. For the "Changelog" section: files in the project repository.
3. For the "Commits" section: the three-dot GitHub comparison.
Looking forward to your thoughts.
Best wishes,
Piotr
[1]
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-comparing-branches-in-pull-requests#about-three-dot-comparison-on-github
[2] https://github.com/ppkarwasz/logging-log4j2/pull/566
[3] https://lists.apache.org/list?announce@apache.org
[log4j] Links to issues in VOTE emails and release notes (Was: [VOTE] Release Apache Log4j `2.25.1` (RC1))
Posted by Volkan Yazıcı <vo...@yazi.ci>.
I see that the most recent VOTE email misses ticket IDs, making it
cumbersome to access associated PRs. I can see the Discussion linked, but
that is not what I am asking for.
Can we share the Issue/PR IDs in the VOTE emails, please?
On Sat, Jul 5, 2025 at 11:08 PM Piotr P. Karwasz <pi...@mailing.copernik.eu>
wrote:
> This is a vote to release the Apache Log4j `2.25.1`.
>
> Website: https://logging.staged.apache.org/log4j/2.25.1/index.html
> GitHub: https://github.com/apache/logging-log4j2
> Commit: bda63362cf405449ff4edc2e4d92353be65c4d4e
> Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j/2.25.1
> Nexus:
>
> https://repository.apache.org:443/content/repositories/orgapachelogging-1320
> Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0
> Review kit:
>
> https://logging.apache.org/logging-parent/release-review-instructions.html[*]
>
> Please download, test, and cast your votes on this mailing list.
> You can optionally also cast your vote in the ATR system[**].
>
> [ ] +1, release the artifacts
> [ ] -1, don't release, because...
>
> This vote is open for 72 hours and will pass unless getting a
> net negative vote count. All votes are welcome and we encourage
> everyone to test the release, but only the Logging Services PMC
> votes are officially counted. At least 3 +1 votes and more
> positive than negative votes are required.
>
> [*] As with the 2.25.0 release, the aggregate SBOM for the log4j-bom
> artifact in version 2.25.1 is not fully reproducible. Two variants may
> be generated that differ only in the ordering of the `jspecify` dependency.
>
> This issue is known and tracked under GitHub issue #3804:
>
> https://github.com/apache/logging-log4j2/issues/3804
>
> To avoid false negatives during verification, reviewers are asked to
> ignore this specific difference by appending the following parameter to
> the build command in the release review instructions:
>
> -Dbuildinfo.ignore="*/log4j-bom-2.25.1-cyclonedx.xml"
>
> [**] Please note that the Apache Trusted Release (ATR) tool is currently
> in alpha, and votes cast through ATR are not officially counted in the
> release process. However, Apache committers are encouraged to try it out
> and provide feedback using the following URL:
>
> https://release-test.apache.org/vote/logging-log4j/2.25.1
>
> == Release Notes
>
> This patch release addresses a dozen bugs in version `2.25.0`, in
> particular:
>
> * Resolves a concurrency issue in the new unified datetime formatter.
> * Fixes build failures affecting Gradle users.
> * Restores backward compatibility with Spring Boot’s common logging
> configuration.
> * Improves handling of edge cases in GraalVM support.
>
> The complete changelog of the `2.25.1` release can be found on the
> staged website at:
>
>
> https://logging.staged.apache.org/log4j/2.25.1/release-notes.html#release-notes-2-25-1
>
Re: [VOTE] Release Apache Log4j `2.25.1` (RC1)
Posted by "Piotr P. Karwasz" <pi...@mailing.copernik.eu>.
Hi all,
On 5.07.2025 23:08, Piotr P. Karwasz wrote:
> Please download, test, and cast your votes on this mailing list.
> You can optionally also cast your vote in the ATR system[**].
>
> [ ] +1, release the artifacts
> [ ] -1, don't release, because...
>
> This vote is open for 72 hours and will pass unless getting a
> net negative vote count. All votes are welcome and we encourage
> everyone to test the release, but only the Logging Services PMC
> votes are officially counted. At least 3 +1 votes and more
> positive than negative votes are required.
I believe sufficient time has been provided for the community to verify
compatibility with version 2.25.1. Therefore, I am casting my +1 vote
and formally closing the vote.
The vote passes with three binding +1 votes from Gary Gregory, Volkan
Yazıcı, and myself.
I will now proceed with the release process.
Piotr
Re: [VOTE] Release Apache Log4j `2.25.1` (RC1)
Posted by Gary Gregory <ga...@gmail.com>.
On Sat, Jul 5, 2025 at 5:54 PM Piotr P. Karwasz
<pi...@mailing.copernik.eu> wrote:
>
> Hi Gary,
>
> On 5.07.2025 23:41, Gary Gregory wrote:
> > But it failed with Docker tests enabled: mvn clean verify -Pdocker
> > -D'docker.showLogs=true'
> >
> > [ERROR] DOCKER> [elasticsearch:8.17.3] "elasticsearch": Timeout after
> > 60764 ms while waiting on tcp port '[/172.19.0.2:9200]'
> > [ERROR] DOCKER> Error occurred during container startup, shutting down...
> > <deleted "ES" output>
> > [INFO] DOCKER> [elasticsearch:8.17.3] "elasticsearch": Stop and
> > removed container a095e36ff18f after 0 ms
> > [ERROR] DOCKER> I/O Error [[elasticsearch:8.17.3] "elasticsearch":
> > Timeout after 60764 ms while waiting on tcp port '[/172.19.0.2:9200]']
>
> Sorry about that. As we have seen in `2.25.0` this is a MacOS-specific
> Docker issue and we'll likely need help from someone familiar with
> Docker on Mac to investigate further. Are there any volunteers who could
> assist?
>
> I do have a Windows installation that I use for tasks that require it,
> so I can look into debugging the tests on that platform. Unfortunately,
> I can’t help with MacOS-specific issues.
>
> In the meantime, could you please open an issue in our tracker so we
> don’t lose track of this?
I created https://github.com/apache/logging-log4j2/issues/3805
Gary
>
> Piotr
Re: [VOTE] Release Apache Log4j `2.25.1` (RC1)
Posted by "Piotr P. Karwasz" <pi...@mailing.copernik.eu>.
Hi Gary,
On 5.07.2025 23:41, Gary Gregory wrote:
> But it failed with Docker tests enabled: mvn clean verify -Pdocker
> -D'docker.showLogs=true'
>
> [ERROR] DOCKER> [elasticsearch:8.17.3] "elasticsearch": Timeout after
> 60764 ms while waiting on tcp port '[/172.19.0.2:9200]'
> [ERROR] DOCKER> Error occurred during container startup, shutting down...
> <deleted "ES" output>
> [INFO] DOCKER> [elasticsearch:8.17.3] "elasticsearch": Stop and
> removed container a095e36ff18f after 0 ms
> [ERROR] DOCKER> I/O Error [[elasticsearch:8.17.3] "elasticsearch":
> Timeout after 60764 ms while waiting on tcp port '[/172.19.0.2:9200]']
Sorry about that. As we have seen in `2.25.0` this is a MacOS-specific
Docker issue and we'll likely need help from someone familiar with
Docker on Mac to investigate further. Are there any volunteers who could
assist?
I do have a Windows installation that I use for tasks that require it,
so I can look into debugging the tests on that platform. Unfortunately,
I can’t help with MacOS-specific issues.
In the meantime, could you please open an issue in our tracker so we
don’t lose track of this?
Piotr
Re: [VOTE] Release Apache Log4j `2.25.1` (RC1)
Posted by Gary Gregory <ga...@gmail.com>.
+1
I tested the src zip file distribution:
- GPG ok
- SHA512 OK
- mvn clean verify
But it failed with Docker tests enabled: mvn clean verify -Pdocker
-D'docker.showLogs=true'
[ERROR] DOCKER> [elasticsearch:8.17.3] "elasticsearch": Timeout after
60764 ms while waiting on tcp port '[/172.19.0.2:9200]'
[ERROR] DOCKER> Error occurred during container startup, shutting down...
<deleted "ES" output>
[INFO] DOCKER> [elasticsearch:8.17.3] "elasticsearch": Stop and
removed container a095e36ff18f after 0 ms
[ERROR] DOCKER> I/O Error [[elasticsearch:8.17.3] "elasticsearch":
Timeout after 60764 ms while waiting on tcp port '[/172.19.0.2:9200]']
Using:
openjdk version "17.0.15" 2025-04-15
OpenJDK Runtime Environment Homebrew (build 17.0.15+0)
OpenJDK 64-Bit Server VM Homebrew (build 17.0.15+0, mixed mode, sharing)
Apache Maven 3.9.10 (5f519b97e944483d878815739f519b2eade0a91d)
Maven home: /opt/homebrew/Cellar/maven/3.9.10/libexec
Java version: 17.0.15, vendor: Homebrew, runtime:
/opt/homebrew/Cellar/openjdk@17/17.0.15/libexec/openjdk.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "15.5", arch: "aarch64", family: "mac"
Darwin ****.local 24.5.0 Darwin Kernel Version 24.5.0: Tue Apr 22
19:53:27 PDT 2025; root:xnu-11417.121.6~2/RELEASE_ARM64_T6041 arm64
Docker version 28.3.0, build 38b7060
Gary
On Sat, Jul 5, 2025 at 5:08 PM Piotr P. Karwasz
<pi...@mailing.copernik.eu> wrote:
>
> This is a vote to release the Apache Log4j `2.25.1`.
>
> Website: https://logging.staged.apache.org/log4j/2.25.1/index.html
> GitHub: https://github.com/apache/logging-log4j2
> Commit: bda63362cf405449ff4edc2e4d92353be65c4d4e
> Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j/2.25.1
> Nexus:
> https://repository.apache.org:443/content/repositories/orgapachelogging-1320
> Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0
> Review kit:
> https://logging.apache.org/logging-parent/release-review-instructions.html[*]
>
> Please download, test, and cast your votes on this mailing list.
> You can optionally also cast your vote in the ATR system[**].
>
> [ ] +1, release the artifacts
> [ ] -1, don't release, because...
>
> This vote is open for 72 hours and will pass unless getting a
> net negative vote count. All votes are welcome and we encourage
> everyone to test the release, but only the Logging Services PMC
> votes are officially counted. At least 3 +1 votes and more
> positive than negative votes are required.
>
> [*] As with the 2.25.0 release, the aggregate SBOM for the log4j-bom
> artifact in version 2.25.1 is not fully reproducible. Two variants may
> be generated that differ only in the ordering of the `jspecify` dependency.
>
> This issue is known and tracked under GitHub issue #3804:
>
> https://github.com/apache/logging-log4j2/issues/3804
>
> To avoid false negatives during verification, reviewers are asked to
> ignore this specific difference by appending the following parameter to
> the build command in the release review instructions:
>
> -Dbuildinfo.ignore="*/log4j-bom-2.25.1-cyclonedx.xml"
>
> [**] Please note that the Apache Trusted Release (ATR) tool is currently
> in alpha, and votes cast through ATR are not officially counted in the
> release process. However, Apache committers are encouraged to try it out
> and provide feedback using the following URL:
>
> https://release-test.apache.org/vote/logging-log4j/2.25.1
>
> == Release Notes
>
> This patch release addresses a dozen bugs in version `2.25.0`, in
> particular:
>
> * Resolves a concurrency issue in the new unified datetime formatter.
> * Fixes build failures affecting Gradle users.
> * Restores backward compatibility with Spring Boot’s common logging
> configuration.
> * Improves handling of edge cases in GraalVM support.
>
> The complete changelog of the `2.25.1` release can be found on the
> staged website at:
>
> https://logging.staged.apache.org/log4j/2.25.1/release-notes.html#release-notes-2-25-1
Re: [DISCUSSION][VOTE] Release Apache Log4j `2.25.1` (RC1)
Posted by "Piotr P. Karwasz" <pi...@mailing.copernik.eu>.
Hi Gary,
On 9.07.2025 14:35, Gary Gregory wrote:
> Dare I ask my our build has Gradle horror in it?
It’s not a horror—it’s a tragedy. A well-intentioned series of events
that slowly spiraled into pain:
## Episode 1: Runtime-Invisible Annotations
Over the past two years, we began using several compile-time annotations
with retention policy `CLASS`:
* `@BaselineIgnore`: Suppresses binary compatibility warnings for
changes that are technically incompatible but safe in practice—for
example, removing a `public` class clearly marked as internal.
* `@SuppressFBWarnings`: Suppresses SpotBugs reports for code that may
appear insecure (e.g. file handling) but is verified to be safe.
* `@InlineMe`: An Error Prone annotation that helps users migrate away
from deprecated methods by suggesting inline replacements.
These annotations are not retained at runtime, so we declared the
corresponding libraries with `provided` scope, ensuring they aren't
transitively exposed to downstream users.
## Episode 2: The JDK Linter Bug
Despite being non-runtime annotations, the JDK’s `-Xlint:classfile`
option still expects these annotations to be present at compile time. If
they're missing, the linter emits warnings.
This behavior seemed questionable, so I filed a bug report with the JDK
team:
https://bugs.openjdk.org/browse/JDK-8342833
While opinions vary on whether this check is useful, it introduced
real-world complications in builds that rely on clean linter output.
## Episode 3: Build Failures and User Complaints
The combination of annotations and linter sensitivity caused build
failures for users compiling with strict flags like
`-Xlint:all -Werror`.
Example issue report and analysis:
https://github.com/apache/logging-log4j2/issues/3110#issuecomment-2423586754
Although most of these annotations are in `log4j-core`—which shouldn't
typically be on users' compile classpaths—many projects still include it
during compilation, intentionally or not.
## Episode 4: Enter GMM
Adding runtime dependencies just to silence compile-time linter warnings
was not acceptable, but Maven’s limited scope model offers no good
workaround. As a result, Maven users were simply told to ignore the
warnings.
However, for Gradle users, a better option emerged: Jendrik proposed
using the Gradle Module Metadata Maven Plugin in
https://github.com/apache/logging-log4j2/issues/3437
This plugin lets us publish enriched metadata that tells Gradle which
dependencies are compile-only but transitive. Gradle can then resolve
annotation libraries during compilation—without leaking them into the
runtime classpath.
## Finale: Version 2.25.0 – Return of the Karma
The plot thickened in the `2.25.0` release, when we unintentionally
upgraded `spotbugs-annotations` to version `4.9.0`—a version **not
compatible with Java 8**.
At first glance, this seemed harmless. After all, `spotbugs-annotations`
is a **compile-only** dependency. If you’re compiling with JDK 11+ and
targeting Java 8, everything should be fine... right?
Unfortunately, no.
Due to a perfect storm of factors—including `spotbugs-annotations`
publishing its own Gradle Module Metadata and our own use of the GMM
plugin—Gradle users compiling for Java 8 found themselves unable to
build against Log4j `2.25.0`.
The issue is documented here:
https://github.com/apache/logging-log4j2/issues/3754
So despite our best intentions, trying to improve metadata fidelity
ended up triggering build failures for a portion of our users. The karma
of well-meant tooling struck back.
Scene,
Piotr
Re: [DISCUSSION][VOTE] Release Apache Log4j `2.25.1` (RC1)
Posted by Gary Gregory <ga...@gmail.com>.
Dare I ask my our build has Gradle horror in it?
Gary
On Wed, Jul 9, 2025, 04:48 Piotr P. Karwasz <pi...@mailing.copernik.eu>
wrote:
> Hi Matt,
> On 8.07.2025 22:14, Matt Sicker wrote:
>
> [image: gist-og-image-54fd7dc0713e.png]
>
> gist:54c8222bd8ef3dabd690994ab35d85d2
> <https://gist.github.com/jvz/54c8222bd8ef3dabd690994ab35d85d2>
> gist.github.com
> <https://gist.github.com/jvz/54c8222bd8ef3dabd690994ab35d85d2>
> <https://gist.github.com/jvz/54c8222bd8ef3dabd690994ab35d85d2>
>
> Logs say the diff is mainly due to compression levels.
>
> Thanks! I was eventually able to reproduce the issue as well. The
> differences appear to stem from the embedded pom.xml and involve the
> Gradle Module Metadata Maven Plugin.
>
> Before publication, the pom.xml is modified in two steps:
>
> 1.
>
> The revision property is resolved by the Flatten Maven Plugin.
> 2.
>
> A <!-- do_not_remove: published-with-gradle-metadata --> comment is
> inserted by the GMM Maven Plugin.
>
> The release candidate includes this comment, while your local build does
> not. This could be due to a variation in plugin execution order—both the
> Maven Source Plugin and the GMM Maven Plugin are bound to the package
> phase, so the final result can depend on which one runs first.
>
> What’s curious is that, in both Maven 3.9.8 and 3.9.10, the Source Plugin
> execution is listed first in the effective POM, so I would have expected
> the comment *not* to appear in the -sources.jar.
>
> By the way: since XML comments can be ignored by parsers, they’re stripped
> out by the Flatten Plugin before the final pom.xml is written. Kudos to
> whoever chose to use a comment rather than something like a
> published-with-gradle-metadata property.
>
> Best,
> Piotr
>
> PS: I attach my result of running `diffoscope` below:
> ---
> log4j-api/target/reference/org.apache.logging.log4j/log4j-api-2.25.1-sources.jar
> +++ log4j-api/target/log4j-api-2.25.1-sources.jar
> ├── zipinfo {}
> │ @@ -1,8 +1,8 @@
> │ -Zip file size: 293959 bytes, number of entries: 177
> │ +Zip file size: 293922 bytes, number of entries: 177
> │ drwxr-xr-x 2.0 unx 0 b- stor 25-Jul-05 19:48 META-INF/
> │ -rw-r--r-- 2.0 unx 64 b- defN 25-Jul-05 19:48
> META-INF/MANIFEST.MF
> │ drwxr-xr-x 2.0 unx 0 b- stor 25-Jul-05 19:48 org/
> │ drwxr-xr-x 2.0 unx 0 b- stor 25-Jul-05 19:48 org/apache/
> │ drwxr-xr-x 2.0 unx 0 b- stor 25-Jul-05 19:48 org/apache/logging/
> │ drwxr-xr-x 2.0 unx 0 b- stor 25-Jul-05 19:48
> org/apache/logging/log4j/
> │ drwxr-xr-x 2.0 unx 0 b- stor 25-Jul-05 19:48
> org/apache/logging/log4j/internal/
> │ @@ -170,10 +170,10 @@
> │ -rw-r--r-- 2.0 unx 8556 b- defN 25-Jul-05 19:48
> org/apache/logging/log4j/util/Timer.java
> │ -rw-r--r-- 2.0 unx 1368 b- defN 25-Jul-05 19:48
> org/apache/logging/log4j/util/TriConsumer.java
> │ -rw-r--r-- 2.0 unx 10556 b- defN 25-Jul-05 19:48
> org/apache/logging/log4j/util/Unbox.java
> │ -rw-r--r-- 2.0 unx 7589 b- defN 25-Jul-05 19:48
> org/apache/logging/log4j/util/internal/SerializationUtil.java
> │ -rw-r--r-- 2.0 unx 1162 b- defN 25-Jul-05 19:48
> org/apache/logging/log4j/util/package-info.java
> │ -rw-r--r-- 2.0 unx 1645 b- defN 25-Jul-05 19:48
> Log4j-charsets.properties
> │ -rw-r--r-- 2.0 unx 143 b- defN 25-Jul-05 19:48
> META-INF/native-image/org.apache.logging.log4j/log4j-api/resource-config.json
> │ --rw-r--r-- 2.0 unx 4513 b- defN 25-Jul-05 19:48
> META-INF/maven/org.apache.logging.log4j/log4j-api/pom.xml
> │ +-rw-r--r-- 2.0 unx 4458 b- defN 25-Jul-05 19:48
> META-INF/maven/org.apache.logging.log4j/log4j-api/pom.xml
> │ -rw-r--r-- 2.0 unx 69 b- defN 25-Jul-05 19:48
> META-INF/maven/org.apache.logging.log4j/log4j-api/pom.properties
> │ -177 files, 1236315 bytes uncompressed, 263029 bytes compressed: 78.7%
> │ +177 files, 1236260 bytes uncompressed, 262992 bytes compressed: 78.7%
> ├── META-INF/maven/org.apache.logging.log4j/log4j-api/pom.xml
> │ ├── META-INF/maven/org.apache.logging.log4j/log4j-api/pom.xml
> │ │ @@ -13,15 +13,14 @@
> │ │ ~ distributed under the License is distributed on an "AS IS" BASIS,
> │ │ ~ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> implied.
> │ │ ~ See the License for the specific language governing permissions
> and
> │ │ ~ limitations under the License.
> │ │ -->
> │ │ <project xmlns="http://maven.apache.org/POM/4.0.0"
> <http://maven.apache.org/POM/4.0.0> xmlns:xsi=
> "http://www.w3.org/2001/XMLSchema-instance"
> <http://www.w3.org/2001/XMLSchema-instance> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> https://maven.apache.org/xsd/maven-4.0.0.xsd"
> <http://maven.apache.org/POM/4.0.0https://maven.apache.org/xsd/maven-4.0.0.xsd>
> >
> │ │ <modelVersion>4.0.0</modelVersion>
> │ │ - <!-- do_not_remove: published-with-gradle-metadata -->
> │ │ <parent>
> │ │ <groupId>org.apache.logging.log4j</groupId>
> │ │ <artifactId>log4j</artifactId>
> │ │ <version>2.25.1</version>
> │ │ <relativePath>../log4j-parent</relativePath>
> │ │ </parent>
> │ │ <artifactId>log4j-api</artifactId>
>
Re: [DISCUSSION][VOTE] Release Apache Log4j `2.25.1` (RC1)
Posted by "Piotr P. Karwasz" <pi...@mailing.copernik.eu>.
Hi Matt,
On 8.07.2025 22:14, Matt Sicker wrote:
> gist-og-image-54fd7dc0713e.png
> gist:54c8222bd8ef3dabd690994ab35d85d2
> <https://gist.github.com/jvz/54c8222bd8ef3dabd690994ab35d85d2>
> gist.github.com
> <https://gist.github.com/jvz/54c8222bd8ef3dabd690994ab35d85d2>
>
> <https://gist.github.com/jvz/54c8222bd8ef3dabd690994ab35d85d2>
>
> Logs say the diff is mainly due to compression levels.
>
Thanks! I was eventually able to reproduce the issue as well. The
differences appear to stem from the embedded |pom.xml| and involve the
Gradle Module Metadata Maven Plugin.
Before publication, the |pom.xml| is modified in two steps:
1.
The |revision| property is resolved by the Flatten Maven Plugin.
2.
A |<!-- do_not_remove: published-with-gradle-metadata -->| comment
is inserted by the GMM Maven Plugin.
The release candidate includes this comment, while your local build does
not. This could be due to a variation in plugin execution order—both the
Maven Source Plugin and the GMM Maven Plugin are bound to the |package|
phase, so the final result can depend on which one runs first.
What’s curious is that, in both Maven 3.9.8 and 3.9.10, the Source
Plugin execution is listed first in the effective POM, so I would have
expected the comment *not* to appear in the |-sources.jar|.
By the way: since XML comments can be ignored by parsers, they’re
stripped out by the Flatten Plugin before the final |pom.xml| is
written. Kudos to whoever chose to use a comment rather than something
like a |published-with-gradle-metadata| property.
Best,
Piotr
PS: I attach my result of running `diffoscope` below:
---
log4j-api/target/reference/org.apache.logging.log4j/log4j-api-2.25.1-sources.jar
+++ log4j-api/target/log4j-api-2.25.1-sources.jar
├── zipinfo {}
│ @@ -1,8 +1,8 @@
│ -Zip file size: 293959 bytes, number of entries: 177
│ +Zip file size: 293922 bytes, number of entries: 177
│ drwxr-xr-x 2.0 unx 0 b- stor 25-Jul-05 19:48 META-INF/
│ -rw-r--r-- 2.0 unx 64 b- defN 25-Jul-05 19:48 META-INF/MANIFEST.MF
│ drwxr-xr-x 2.0 unx 0 b- stor 25-Jul-05 19:48 org/
│ drwxr-xr-x 2.0 unx 0 b- stor 25-Jul-05 19:48 org/apache/
│ drwxr-xr-x 2.0 unx 0 b- stor 25-Jul-05 19:48 org/apache/logging/
│ drwxr-xr-x 2.0 unx 0 b- stor 25-Jul-05 19:48
org/apache/logging/log4j/
│ drwxr-xr-x 2.0 unx 0 b- stor 25-Jul-05 19:48
org/apache/logging/log4j/internal/
│ @@ -170,10 +170,10 @@
│ -rw-r--r-- 2.0 unx 8556 b- defN 25-Jul-05 19:48
org/apache/logging/log4j/util/Timer.java
│ -rw-r--r-- 2.0 unx 1368 b- defN 25-Jul-05 19:48
org/apache/logging/log4j/util/TriConsumer.java
│ -rw-r--r-- 2.0 unx 10556 b- defN 25-Jul-05 19:48
org/apache/logging/log4j/util/Unbox.java
│ -rw-r--r-- 2.0 unx 7589 b- defN 25-Jul-05 19:48
org/apache/logging/log4j/util/internal/SerializationUtil.java
│ -rw-r--r-- 2.0 unx 1162 b- defN 25-Jul-05 19:48
org/apache/logging/log4j/util/package-info.java
│ -rw-r--r-- 2.0 unx 1645 b- defN 25-Jul-05 19:48
Log4j-charsets.properties
│ -rw-r--r-- 2.0 unx 143 b- defN 25-Jul-05 19:48
META-INF/native-image/org.apache.logging.log4j/log4j-api/resource-config.json
│ --rw-r--r-- 2.0 unx 4513 b- defN 25-Jul-05 19:48
META-INF/maven/org.apache.logging.log4j/log4j-api/pom.xml
│ +-rw-r--r-- 2.0 unx 4458 b- defN 25-Jul-05 19:48
META-INF/maven/org.apache.logging.log4j/log4j-api/pom.xml
│ -rw-r--r-- 2.0 unx 69 b- defN 25-Jul-05 19:48
META-INF/maven/org.apache.logging.log4j/log4j-api/pom.properties
│ -177 files, 1236315 bytes uncompressed, 263029 bytes compressed: 78.7%
│ +177 files, 1236260 bytes uncompressed, 262992 bytes compressed: 78.7%
├── META-INF/maven/org.apache.logging.log4j/log4j-api/pom.xml
│ ├── META-INF/maven/org.apache.logging.log4j/log4j-api/pom.xml
│ │ @@ -13,15 +13,14 @@
│ │ ~ distributed under the License is distributed on an "AS IS" BASIS,
│ │ ~ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
│ │ ~ See the License for the specific language governing permissions and
│ │ ~ limitations under the License.
│ │ -->
│ │ <project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
https://maven.apache.org/xsd/maven-4.0.0.xsd">
│ │ <modelVersion>4.0.0</modelVersion>
│ │ - <!-- do_not_remove: published-with-gradle-metadata -->
│ │ <parent>
│ │ <groupId>org.apache.logging.log4j</groupId>
│ │ <artifactId>log4j</artifactId>
│ │ <version>2.25.1</version>
│ │ <relativePath>../log4j-parent</relativePath>
│ │ </parent>
│ │ <artifactId>log4j-api</artifactId>
Re: [DISCUSSION][VOTE] Release Apache Log4j `2.25.1` (RC1)
Posted by Matt Sicker <ma...@musigma.org>.
https://gist.github.com/jvz/54c8222bd8ef3dabd690994ab35d85d2
gist:54c8222bd8ef3dabd690994ab35d85d2
gist.github.com
Logs say the diff is mainly due to compression levels.
> On Jul 8, 2025, at 13:38, Piotr P. Karwasz <pi...@mailing.copernik.eu> wrote:
>
> Hi Matt,
>
> On 8.07.2025 18:34, Matt Sicker wrote:
>> The diffoscope output for the module file is simple:
>>
>> [...]
>> │ "createdBy": {
>> │ "maven": {
>> │ - "version": "3.9.8"
>> │ + "version": "3.9.10"
>> │ }
>
> I didn't know about this aspect of the Gradle Module Metadata (GMM)
> Maven Plugin, but the error makes sense now: the difference is due to
> the Maven version used.
>
> To address this, I’ve opened a feature request in the GMM Maven Plugin
> to stop generating the optional `createdBy` field altogether:
>
> https://github.com/gradlex-org/gradle-module-metadata-maven-plugin/issues/43
>
> This should improve reproducibility and make it easier to verify future
> Log4j releases.
>
>> The diffoscope output for the other file has substantial changes
>> (probably related to version differences).
>
> The differences in the `-sources.jar` are a bit more concerning. While
> it’s more of a documentation artifact than the actual source code of
> Log4j, unexpected changes there still raise questions.
>
> Unlike the `.module` file issue—which I can reproduce by switching to
> Maven 3.9.10—I haven't been able to reproduce the `-sources.jar`
> differences on Linux. Could you upload your `diffoscope` output to a
> Gist or share a summary of the key differences you’re seeing?
>
> Piotr
>
>
Re: [DISCUSSION][VOTE] Release Apache Log4j `2.25.1` (RC1)
Posted by "Piotr P. Karwasz" <pi...@mailing.copernik.eu>.
Hi Matt,
On 8.07.2025 18:34, Matt Sicker wrote:
> The diffoscope output for the module file is simple:
>
> [...]
> │ "createdBy": {
> │ "maven": {
> │ - "version": "3.9.8"
> │ + "version": "3.9.10"
> │ }
I didn't know about this aspect of the Gradle Module Metadata (GMM)
Maven Plugin, but the error makes sense now: the difference is due to
the Maven version used.
To address this, I’ve opened a feature request in the GMM Maven Plugin
to stop generating the optional `createdBy` field altogether:
https://github.com/gradlex-org/gradle-module-metadata-maven-plugin/issues/43
This should improve reproducibility and make it easier to verify future
Log4j releases.
> The diffoscope output for the other file has substantial changes
> (probably related to version differences).
The differences in the `-sources.jar` are a bit more concerning. While
it’s more of a documentation artifact than the actual source code of
Log4j, unexpected changes there still raise questions.
Unlike the `.module` file issue—which I can reproduce by switching to
Maven 3.9.10—I haven't been able to reproduce the `-sources.jar`
differences on Linux. Could you upload your `diffoscope` output to a
Gist or share a summary of the key differences you’re seeing?
Piotr
Re: [DISCUSSION][VOTE] Release Apache Log4j `2.25.1` (RC1)
Posted by Matt Sicker <ma...@musigma.org>.
The diffoscope output for the module file is simple:
diffoscope log4j-api/target/reference/org.apache.logging.log4j/log4j-api-2.25.1.module log4j-api/target/publications/maven/module.json
--- log4j-api/target/reference/org.apache.logging.log4j/log4j-api-2.25.1.module
+++ log4j-api/target/publications/maven/module.json
├── Pretty-printed
│ @@ -5,15 +5,15 @@
│ },
│ "group": "org.apache.logging.log4j",
│ "module": "log4j-api",
│ "version": "2.25.1"
│ },
│ "createdBy": {
│ "maven": {
│ - "version": "3.9.8"
│ + "version": "3.9.10"
│ }
│ },
│ "formatVersion": "1.1",
│ "variants": [
│ {
│ "attributes": {
│ "org.gradle.category": "library”,
The diffoscope output for the other file has substantial changes (probably related to version differences).
> On Jul 8, 2025, at 03:36, Piotr P. Karwasz <pi...@mailing.copernik.eu> wrote:
>
> Hi Matt,
>
> On 7.07.2025 22:34, Matt Sicker wrote:
>> Something is buggy for me in the Maven wrapper script which causes this error to print out:
>>
>> mvnw: line 114: mvnw/.mvn/wrapper/maven-wrapper.properties: Not a directory
>> cannot read distributionUrl property in mvnw/.mvn/wrapper/maven-wrapper.properties
>
> This is a known bug in Maven Wrapper—see Volkan's e-mail.
>
>> When I tried running the build with a local copy of Maven, I get a different error:
>>
>> [ERROR] size mismatch log4j-api-2.25.1-sources.jar: investigate with diffoscope log4j-api/target/reference/org.apache.logging.log4j/log4j-api-2.25.1-sources.jar log4j-api/target/log4j-api-2.25.1-sources.jar
>> [ERROR] size mismatch log4j-api-2.25.1.module: investigate with diffoscope log4j-api/target/reference/org.apache.logging.log4j/log4j-api-2.25.1.module log4j-api/target/publications/maven/module.json
>> [ERROR] Reproducible Build output summary: 3 files ok, 2 different
>> [ERROR] see diff log4j-api/target/reference/log4j-api-2.25.1.buildinfo log4j-api/target/log4j-api-2.25.1.buildinfo
>>
>> The diff:
>
> As I’ve mentioned before—e.g., in a similar report from Gary[1]—running
> the final `diff` command is rarely useful. It only confirms that files
> differ (as already stated) and in this case, mainly reveals that your
> build was done on macOS.
>
> Instead, could you please run the `diffoscope` commands listed earlier
> in the output? These are much more helpful for diagnosing actual
> differences:
>
>
> diffoscope
> log4j-api/target/reference/org.apache.logging.log4j/log4j-api-2.25.1-sources.jar
> log4j-api/target/log4j-api-2.25.1-sources.jar
> diffoscope
> log4j-api/target/reference/org.apache.logging.log4j/log4j-api-2.25.1.module
> log4j-api/target/publications/maven/module.json
>
> Piotr
>
> PS: I’ve submitted a bug report / feature request[2] to improve the
> clarity of this error message. If you have a moment, could you take a
> look and let me know if the suggestions make sense?
>
> [1] https://lists.apache.org/thread/q8vyzndb4g6sfzk0xw8ofgnfv32o6ox6
> [2] https://github.com/apache/maven-artifact-plugin/issues/175
>
>
>
>
[DISCUSSION][VOTE] Release Apache Log4j `2.25.1` (RC1)
Posted by "Piotr P. Karwasz" <pi...@mailing.copernik.eu>.
Hi Matt,
On 7.07.2025 22:34, Matt Sicker wrote:
> Something is buggy for me in the Maven wrapper script which causes this error to print out:
>
> mvnw: line 114: mvnw/.mvn/wrapper/maven-wrapper.properties: Not a directory
> cannot read distributionUrl property in mvnw/.mvn/wrapper/maven-wrapper.properties
This is a known bug in Maven Wrapper—see Volkan's e-mail.
> When I tried running the build with a local copy of Maven, I get a different error:
>
> [ERROR] size mismatch log4j-api-2.25.1-sources.jar: investigate with diffoscope log4j-api/target/reference/org.apache.logging.log4j/log4j-api-2.25.1-sources.jar log4j-api/target/log4j-api-2.25.1-sources.jar
> [ERROR] size mismatch log4j-api-2.25.1.module: investigate with diffoscope log4j-api/target/reference/org.apache.logging.log4j/log4j-api-2.25.1.module log4j-api/target/publications/maven/module.json
> [ERROR] Reproducible Build output summary: 3 files ok, 2 different
> [ERROR] see diff log4j-api/target/reference/log4j-api-2.25.1.buildinfo log4j-api/target/log4j-api-2.25.1.buildinfo
>
> The diff:
As I’ve mentioned before—e.g., in a similar report from Gary[1]—running
the final `diff` command is rarely useful. It only confirms that files
differ (as already stated) and in this case, mainly reveals that your
build was done on macOS.
Instead, could you please run the `diffoscope` commands listed earlier
in the output? These are much more helpful for diagnosing actual
differences:
diffoscope
log4j-api/target/reference/org.apache.logging.log4j/log4j-api-2.25.1-sources.jar
log4j-api/target/log4j-api-2.25.1-sources.jar
diffoscope
log4j-api/target/reference/org.apache.logging.log4j/log4j-api-2.25.1.module
log4j-api/target/publications/maven/module.json
Piotr
PS: I’ve submitted a bug report / feature request[2] to improve the
clarity of this error message. If you have a moment, could you take a
look and let me know if the suggestions make sense?
[1] https://lists.apache.org/thread/q8vyzndb4g6sfzk0xw8ofgnfv32o6ox6
[2] https://github.com/apache/maven-artifact-plugin/issues/175
[DISCUSSION][VOTE] Release Apache Log4j `2.25.1` (RC1)
Posted by "Piotr P. Karwasz" <pi...@mailing.copernik.eu>.
Hi Volkan,
On 8.07.2025 09:29, Volkan Yazıcı wrote:
> I could not resolve the `artifact:compare` failure on
> `log4j-parent`. This is an important problem, but not
> a release blocker, AFAICT.
Just to clarify—are you referring to the reproducibility issue in
`log4j-bom`, or is this a separate problem you encountered with
`org.apache.logging.log4j:log4j`?
Once I gain a better understanding of what’s happening with these SBOMs,
I plan to address the issue in the CycloneDX Maven Plugin.
On a related note, I’ve been re-evaluating the usefulness of the
“aggregate” SBOMs (`log4j-bom` and `log4j`):
* These SBOMs don’t accurately describe the dependencies of `log4j-bom`
or `log4j`. For POM files, the true dependencies are their parent POMs.
* The way the `makeAggregateBom` goal is currently bound in the Maven
lifecycle means that the generated SBOMs lack critical details—such as
the checksums of Log4j’s binary artifacts—since the execution happens
before those artifacts are built.
* Even if we consider the aggregate SBOM to describe the build-time
dependencies of the source archive, it still misses key components,
including Maven plugins used in the build process and test/provided
dependencies.
Given these limitations, I’m considering replacing the
`makeAggregateBom` execution with `makeBom`. This would generate SBOMs
only for binary JARs, capturing the actual compile- and runtime-relevant
dependencies for each artifact.
What do you think?
Piotr
Re: [VOTE] Release Apache Log4j `2.25.1` (RC1)
Posted by Volkan Yazıcı <vo...@yazi.ci>.
+1
✅ Signatures
✅ Checksums
✅ `./mvnw verify`
*Build platform:*
- Xubuntu 24.04.2
- OpenJDK 17.0.15+6-Ubuntu-0ubuntu124.04
- x86_64
*Notes:*
I had the same issues reported by Matt.
`mvnw` needed an `chmod u+x mvnw` amendment.
This is a known issue, I reported it to Maven[1][2],
Piotr provided a PR[3], yet...
I could not resolve the `artifact:compare` failure on
`log4j-parent`. This is an important problem, but not
a release blocker, AFAICT.
[1] https://issues.apache.org/jira/browse/MWRAPPER-161
[2] https://github.com/apache/maven-wrapper/issues/305
[3] https://github.com/apache/maven-wrapper/pull/329
On Mon, Jul 7, 2025 at 10:34 PM Matt Sicker <ma...@musigma.org> wrote:
> Something is buggy for me in the Maven wrapper script which causes this
> error to print out:
>
> mvnw: line 114: mvnw/.mvn/wrapper/maven-wrapper.properties: Not a directory
> cannot read distributionUrl property in
> mvnw/.mvn/wrapper/maven-wrapper.properties
>
> When I tried running the build with a local copy of Maven, I get a
> different error:
>
> [ERROR] size mismatch log4j-api-2.25.1-sources.jar: investigate with
> diffoscope
> log4j-api/target/reference/org.apache.logging.log4j/log4j-api-2.25.1-sources.jar
> log4j-api/target/log4j-api-2.25.1-sources.jar
> [ERROR] size mismatch log4j-api-2.25.1.module: investigate with diffoscope
> log4j-api/target/reference/org.apache.logging.log4j/log4j-api-2.25.1.module
> log4j-api/target/publications/maven/module.json
> [ERROR] Reproducible Build output summary: 3 files ok, 2 different
> [ERROR] see diff log4j-api/target/reference/log4j-api-2.25.1.buildinfo
> log4j-api/target/log4j-api-2.25.1.buildinfo
>
> The diff:
>
> 0a1,15
> > # https://reproducible-builds.org/docs/jvm/
> > buildinfo.version=1.0-SNAPSHOT
> >
> > name=Apache Log4j API
> > group-id=org.apache.logging.log4j
> > artifact-id=log4j-api
> > version=2.25.1
> >
> > # source information
> > source.scm.uri=scm:git:https://github.com/apache/logging-log4j2.git
> > source.scm.tag=rel/2.25.1
> >
> > # build instructions
> > build-tool=mvn
> >
> 2,3c17,19
> < java.version=17 (from MANIFEST.MF Build-Jdk-Spec)
> < os.name=Unix (from pom.properties newline)
> ---
> > java.version=17.0.15
> > java.vendor=Apple Inc.
> > os.name=Mac OS X
> 4a21,25
> > # Maven rebuild instructions and effective environment
> > mvn.version=3.9.10
> >
> > # output
> >
> 22,23c43,44
> < outputs.3.length=293959
> <
> outputs.3.checksums.sha512=a85f1d8b55567e579d23a5c73f3d7345dce5b835cb792f542f64d28250d307531f0e91817e61bd9ca6a2069d6992641e65ed4c3a3b8d699b52ebd6bf4c08e18c
> ---
> > outputs.3.length=293922
> >
> outputs.3.checksums.sha512=104f3d1d5c4ba247b919f622653eb9f8f44d3780b742104d4b68cc09af5b30655e202480f5a0a957efeb85260e10b440c56c2fac8c114927bbb194df135c9c24
> 27,28c48,49
> < outputs.4.length=2906
> <
> outputs.4.checksums.sha512=6811bd5c5b51012c2734331338089aade55708afa619761cbe129a1fc68d6e1be3c8f32d601689d0811784496ad2523979106f92560086b0f107dbb691e87511
> ---
> > outputs.4.length=2907
> >
> outputs.4.checksums.sha512=bdfb25da0e910bd45e1f30007e9ab19aa3a802e5471d6266599f2b231f8a8a39e0f3790e212b4dac5c96e3642ae04b962a414c95fb6f7f760807358973ba9a43
>
>
> > On Jul 5, 2025, at 16:08, Piotr P. Karwasz <pi...@mailing.copernik.eu>
> wrote:
> >
> > te
>
>
Re: [VOTE] Release Apache Log4j `2.25.1` (RC1)
Posted by Matt Sicker <ma...@musigma.org>.
Something is buggy for me in the Maven wrapper script which causes this error to print out:
mvnw: line 114: mvnw/.mvn/wrapper/maven-wrapper.properties: Not a directory
cannot read distributionUrl property in mvnw/.mvn/wrapper/maven-wrapper.properties
When I tried running the build with a local copy of Maven, I get a different error:
[ERROR] size mismatch log4j-api-2.25.1-sources.jar: investigate with diffoscope log4j-api/target/reference/org.apache.logging.log4j/log4j-api-2.25.1-sources.jar log4j-api/target/log4j-api-2.25.1-sources.jar
[ERROR] size mismatch log4j-api-2.25.1.module: investigate with diffoscope log4j-api/target/reference/org.apache.logging.log4j/log4j-api-2.25.1.module log4j-api/target/publications/maven/module.json
[ERROR] Reproducible Build output summary: 3 files ok, 2 different
[ERROR] see diff log4j-api/target/reference/log4j-api-2.25.1.buildinfo log4j-api/target/log4j-api-2.25.1.buildinfo
The diff:
0a1,15
> # https://reproducible-builds.org/docs/jvm/
> buildinfo.version=1.0-SNAPSHOT
>
> name=Apache Log4j API
> group-id=org.apache.logging.log4j
> artifact-id=log4j-api
> version=2.25.1
>
> # source information
> source.scm.uri=scm:git:https://github.com/apache/logging-log4j2.git
> source.scm.tag=rel/2.25.1
>
> # build instructions
> build-tool=mvn
>
2,3c17,19
< java.version=17 (from MANIFEST.MF Build-Jdk-Spec)
< os.name=Unix (from pom.properties newline)
---
> java.version=17.0.15
> java.vendor=Apple Inc.
> os.name=Mac OS X
4a21,25
> # Maven rebuild instructions and effective environment
> mvn.version=3.9.10
>
> # output
>
22,23c43,44
< outputs.3.length=293959
< outputs.3.checksums.sha512=a85f1d8b55567e579d23a5c73f3d7345dce5b835cb792f542f64d28250d307531f0e91817e61bd9ca6a2069d6992641e65ed4c3a3b8d699b52ebd6bf4c08e18c
---
> outputs.3.length=293922
> outputs.3.checksums.sha512=104f3d1d5c4ba247b919f622653eb9f8f44d3780b742104d4b68cc09af5b30655e202480f5a0a957efeb85260e10b440c56c2fac8c114927bbb194df135c9c24
27,28c48,49
< outputs.4.length=2906
< outputs.4.checksums.sha512=6811bd5c5b51012c2734331338089aade55708afa619761cbe129a1fc68d6e1be3c8f32d601689d0811784496ad2523979106f92560086b0f107dbb691e87511
---
> outputs.4.length=2907
> outputs.4.checksums.sha512=bdfb25da0e910bd45e1f30007e9ab19aa3a802e5471d6266599f2b231f8a8a39e0f3790e212b4dac5c96e3642ae04b962a414c95fb6f7f760807358973ba9a43
> On Jul 5, 2025, at 16:08, Piotr P. Karwasz <pi...@mailing.copernik.eu> wrote:
>
> te