[log4j] Links to issues in VOTE emails and release notes (Was: [VOTE] Release Apache Log4j `2.25.1` (RC1))
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 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 >
[DISCUSSION][VOTE] Release Apache Log4j `2.25.1` (RC1)
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
Re: [VOTE] Release Apache Log4j `2.25.1` (RC1)
+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 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 > wrote: > > > > te > >
Release notes, changelog and commits
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 `annou...@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?annou...@apache.org
[DISCUSSION][VOTE] Release Apache Log4j `2.25.1` (RC1)
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: [DISCUSSION][VOTE] Release Apache Log4j `2.25.1` (RC1)
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 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
>
>
>
>
Re: [DISCUSSION][VOTE] Release Apache Log4j `2.25.1` (RC1)
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)
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 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
>
>
