Hi all, To reassure those that fear that splitting components over multiple repos can make integration between Log4j components more difficult, I have submitted a couple of PRs last week to simplify that:
* I have introduced a new reproducibility check in apache/logging-parent#271[1] and apache/logging-log4j2#3101[2] that verifies the reproducibility of artifacts after they have been deployed to a Nexus repo. Unlike the previous reproducibility check, this one does not run in the same job (on the same machine) as the build, runs on multiple platforms and compares the artifacts against those published in **remote** Maven repos (not the local one). The CI run [3] confirms that the reproducibility of Log4j does not depend on the platform. * We don't really have integration tests in `logging-log4j2`: those that we have don't run in the build, those that run don't use the final JAR file, but `target/classes` and they certainly don't use JPMS. Therefore I consider `logging-log4j-samples` as the source of integration tests. In PR apache/logging-log4j2#3105[4] I introduce a workflow job that runs all the tests we have in `logging-log4j-samples` after any kind of deployment in `logging-log4j2`. Could you review the PRs above? Does this approach address your arguments against releasing some Log4j artifacts separately from a separate repos? Piotr [1] https://github.com/apache/logging-parent/pull/271 [2] https://github.com/apache/logging-log4j2/pull/3101 [3] https://github.com/apache/logging-log4j2/actions/runs/11387867995 [4] https://github.com/apache/logging-log4j2/pull/3105
