Reply is inline below: > On Jul 2, 2023, at 2:57 PM, Volkan Yazıcı <vol...@yazi.ci> wrote: > > *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.
This sounds great so far! > 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. A Java build using Java? Imagine that! I’ve only seen a very small handful of Java projects that use actual Java code in their build and not an XML thesis. I like this approach for handling this part of the build, especially since it’s not Groovy+Gradle where things get hard to follow. > *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. Making a source release to downloads.a.o along with publishing all our usual jar files (binaries and sources) covers our main channels here. When Log4j2 was mainly the API and Core modules, then it seemed more reasonable that people would be downloading the jar files without a dependency manager, but with the increased modularity and continued industry convergence on using dependency managers, I think this approach would be sufficient. > *What is next?* > > Distribute this logic in `logging-parent` POM and reuse it in > `logging-log4j-transform` as a PoC. I’d love to reuse this in the Kotlin API, too. The easier this all is to use, the easier it’ll be to maintain multiple repositories.
