Re: [VOTE] Release Apache Log4j `2.26.0`

"Piotr P. Karwasz" <[email protected]> Mon, 4 May 2026 20:18:55 +0200
Newsgroups gmane.comp.jakarta.log4j.devel
Message-ID <78e488da-8b42-4dc9-b398-9e16542ef385__19547.9761388682$1777918888$gmane$org@mailing.copernik.eu>
Hi Gary,

On 4.05.2026 14:16, Gary Gregory wrote:
> I tried to adapt the review kit to my setup, running:
> 
> sh mvn verify -P docker \
>   -Prelease artifact:compare \
>   -Dreference.repo=https://repository.apache.org/content/repositories/orgapachelogging-1325


Reproducibility likely requires:

    export CI=true

This variable toggles the activation of two profiles (`java8-tests` and
`java8-incompat-fixes`) that allow CI to run tests against a JDK 8
toolchain. Unfortunately, it also has some side effects on the generated
artifacts:

- `jspecify` appears in the `test` scope instead of `provided` scope.
The artifact is added to the `test` scope by the profile as a workaround
for a JDK 8 bug, so the SBOMs generated with `CI=true` and `CI=false`
differ slightly in where `jspecify` appears.
- For reasons I couldn't fully pin down, the POM files embedded in the
`*-sources.jar` archive may differ by a comment. The order in which a
POM-modifying plugin and `maven-source-plugin` execute differs between
`CI=true` and `CI=false`.

We should almost certainly fix this going forward, for example, by
running the `deploy-release` workflow without the JDK 8 fixups and
reserving those for `build` runs[*].

Piotr

[*] As an aside: the `build` workflow is a misnomer. Its main purpose is
to run unit tests, and building the artifacts is just a side effect.
Conversely, the main purpose of `deploy-release` is to build the
artifacts (without testing) and deploy them to the staging repository.