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
