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.