Re: Bridges in 2.x and 3.x
Hi Gary, On 23.10.2024 12:50, Gary D. Gregory wrote: Another batch of repositories? -1 and you must be joking. We really are going off the map here IMO :( Releasing different jars from one repo is the same as releasing jars from one SSD: A repo is just a folder with subfolders you can organize as you best see fit. So why have 10 repos? Or how ever many we have now splintered Log4j into? Right now we have: `logging-log4j-flume`: the Flume Appender that is waiting for Flume to exit its dormant state. `logging-log4j-jakarta`: contains the integration of Log4j Core 3 with Jakarta EE. `logging-log4j-jmx-gui`: a standalone application to access Log4j Core 2 through JMX. `logging-log4j-kotlin`: the Kotlin API. `logging-log4j-scala`: the Scala API. `logging-log4j-tools`: a set of tools for private consumption (incubating). `logging-log4j-transform`: a set of tools for public consumption (incubating). `logging-log4j2`: contains Log4j API, the bridges, Log4j Core and its extensions in the `2.x` branch, just Log4j Core and its extensions in the `main` branch. IMHO this is much less than the 44 repositories of Apache Commons. The sub-projects are documented on the webpage, but I can add a short guide to the README.adoc of `logging-log4j2`, the same way Tatu linked all its sub-projects in the main Jackson repository[1]. Is your -1 a veto? Can you propose a different technical solution so that: * The bridge code is not duplicated in multiple branches. * We don't need to make special Log4j releases just because SLF4J changed something (like 2.19.0, which didn't change anything in Log4j). Ceki is considering bumping the SLF4J requirements to Java 11[2]. I always found it annoying to upgrade a library even if nothing changed (e.g. in SLF4J 1.7.x most recent changes were in the bridges to some end-of-life legacy APIs). * We don't need to modify our build scripts so we can publish `logging-log4j2` without a folder and publish the folder separately. Don't get me wrong, this is feasible, but I would only do it for technical reasons: e.g. `logging-log4j-samples` needs a different toolchain to compile the JDK, GraalVM and Android examples. Piotr [1] https://github.com/FasterXML/jackson [2] https://github.com/qos-ch/slf4j/discussions/379
Re: Bridges in 2.x and 3.x
Gary, With the changes that have been made the bridges only have a dependency on Logj4 API - which is only in the 2.x branch. Should these artifacts only be on the 2.x branch as well? These bridges don’t change nearly as often as core or even api do. IMO releasing them with every release doesn’t make a lot of sense. To be honest, I would have suggested that the API and everything that is only dependent on the API (except for core) be in a separate repo with its own release schedule. This would match pretty much what SLF4J does. Are you suggesting that the bridges be included in both 2.x and main? Are you suggesting that the bridges MUST be versioned the same as 2.x despite them almost never having any changes? I’m simply trying to understand what your rationale is here. Ralph > On Oct 23, 2024, at 3:50 AM, Gary D. Gregory wrote: > > Another batch of repositories? -1 and you must be joking. We really are going > off the map here IMO :( > > Releasing different jars from one repo is the same as releasing jars from one > SSD: A repo is just a folder with subfolders you can organize as you best see > fit. So why have 10 repos? Or how ever many we have now splintered Log4j > into? It's not like we document it. I bet devs put all Log4j repos in the > same folder anyway... Does STF funding work by getting paid on a per repo > basis? Sigh. > > At some point in the future I only hope someone will reign in this mad cow > bug we've caught and use a mono repo for Log4j. > > I'm have some work to contributing here soon but this is all noise that gets > in the way IMO. > > Gary >
Multi-repository deploy workflows
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
