*Abstract:* `log4j-tools` 0.4.0 release contains a `beanshell-maven-plugin` block that created the distribution ZIP in a way that addresses all past concerns of PMC, it is reusable by other projects without any changes, integrates with `log4j-changelog-maven-plugin`, uses JGit to collect sources, and composed of 79 lines of BeanShell script <https://github.com/apache/logging-log4j-tools/blob/release/0.4.0/pom.xml#L467> .
It is no secret that I have been spending quite some time on _perfecting_ the `logging-log4j-tools` Maven and release infrastructure. I will soon be breaking the `logging-log4j2` repository into multiple repositories, and there I want to take the `l-l-tools` as reference. Hence, my push for the simplest and reusable Maven+release infra there. `l-l-tools` has the simplest ASF-compliant releasing procedure <https://github.com/apache/logging-log4j-tools/blob/release/0.4.0/RELEASING.adoc> out there in the wild. Though my use of `git ls-files | sort | zip` to generate "the distribution" ZIP has been a subject of certain discussions. I share an exhaustive list of all the complaints so far: 1. `git ls-files | sort | zip` is not reproducible! 2. `git ls-files | sort | zip` cannot be executed on Windows! 3. Why do we package `.github`, `.asf.yaml`, etc. files that are not relevant for the release in the distribution? 4. The distribution must contain binaries, not only sources, since there are people still living in 1998, downloading JARs from the ASF website, and copy-pasting them into their servers. 5. The distribution must contain the release notes, because... we have been doing this for more than decade while releasing Log4j. 6. Why don't we simply use `maven-assembly-plugin` just like we do in Log4j? In `l-l-tools` 0.4.0 release, I have done something different, addressing all these concerns and delivering even more! `l-l-tools` 0.4.0 release contains a `beanshell-maven-plugin` block creating the distribution ZIP such that - The entire logic is composed of 79 lines of BeanShell – including import statements, comments, and empty lines! - `RELEASE-NOTES.md` is generated from `src/changelog` and included in the distribution ZIP. - `git ls-files` output is obtained using JGit (in BeanShell) and compressed in a reproducible & platform-independent way. - JARs to be added to the distribution ZIP are matched using regex. I will share a Q&A below. *`git ls-files | sort | zip` is not reproducible and doesn't work on Windows* Long story short, this is correct. The new release procedure doesn't have these shortcomings. *Why do we package `.github`, `.asf.yaml`, etc. files that are not relevant for the release in the distribution?* I completely disagree with this statement. A release should contain the shallow VCS clone used to create the release, such that, if everything that has a hold on it evaporates, I should be able to kick-start it without breaking a sweat. That is why, I am strongly opinionated that the distribution should contain "sources" which are identical to `git ls-files`, nothing more, nothing less. *The distribution must contain binaries too* I disagree with this sentiment. Yet there are multiple PMC members practicing this "copy-pasting downloaded JARs to the server" tradition. Hence, the new release procedure bundles binaries too. *The distribution must contain the release notes* The new release procedure generates and bundles the release notes. *Why don't we simply use `maven-assembly-plugin`* `maven-assembly-plugin` has following problems: - It doesn't integrate with Git. It only includes module sources. It is a non-trivial task to re-generate and compile a project only using `maven-assembly-plugin` provided sources. - List of artifacts to be included must be explicitly provided, and hence, manually maintained. This is an error-prone design, since if one adds a new module and forgets to add it to the `log4j-distribution/pom.xml`, it won't be included in the distribution. - It is not reusable: One cannot copy-paste `log4j-distribution/pom.xml` to `logging-parent` and reuse that distribution logic in other projects. - It is not possible to integrate it with `log4j-changelog:export` output. One cannot configure it to first run `log4j-changelog:export` goal and include the generated `target/site/release-notes/${revision}.md` as `RELEASE-NOTES.md`. The new release procedure integrates with Git (using JGit), scans folders for JARs, integrates with `log4j-changelog`, and can be reused by simply sharing it in `logging-parent`. *Why don't we simply ship this logic in Java as a separate module?* Then it won't be something we can easily deliver in `logging-parent` POM and reuse. *Has anybody else fact-checked these claims and/or reviewed the implementation?* Yes. Piotr and Romain Manni-Bucau <https://the-asf.slack.com/archives/C7Q9JB404/p1688066078340959>. *Can I see this new release procedure in action?* See how `log4j-tools` 0.4.0 release is performed using this GitHub Actions workflow run <https://github.com/apache/logging-log4j-tools/actions/runs/5438016143/jobs/9888975801>. Or clone `logging-log4j-tools`, switch to `release/0.4.0` branch, run `./mvnw package -DskipTests && ./mvnw -P distribution`. *What is next?* Distribute this logic in `logging-parent` POM and reuse it in `logging-log4j-transform` as a PoC.
