Here are my thoughts:
- I like 2.x as it is now as a mono-repo.
- I like a mon-repo in general because:
-- Everything is released together with the same version. There is no
mystery of what works with what, what we tested with what. See the bugs
with Maven plugins mysteriously breaking as counter-examples.
-- A mono-repo gives me the confidence that everything works *together* because
it was built and tested *together*.
-- I or Dependabot can update one Maven property in in my POM for all of
Log4j and I'm done.
-- I *don't *want a Dependabot PR for each Log4j jar because I use
log4j-api v1, log4j-core v2, log4j-foo v3, log4j-bar v4, log4j-boo v5,
log4j-arg v6, and so on.
-- A mono-repo is the lowest barrier to entry for new contributors. Don't
force me to learn more weird tooling and procedures, Maven and plain git
are enough magic for anyone.
- I am OK with keeping building upon 2.x as the future of Log4j and
keeping binary compatibility as long as possible
- I would like to see all modules split up such that there are no optional
dependencies. I want to be able to depend on a log4j-console for simple
apps and get a minimal install.
- I am horrified to read "Enables module rot". Hiding a module from a user
and letting it "rot" is terrible: It is not a development process and
reflects poorly on us IMO. To drop a module, we should: Agree in a poll or
vote, deprecate it for removal, and then remove it. That's a process. Not
"Oh, well, it's been rotting on the side over there and it doesn't work
anymore, oh well! Sorry!"

- 3.x is a new major version and provides a unique opportunity:
-- Breaking binary compatibility.
-- This also means a new artifactID and root package name.
-- Apps using the 1.x API, the 2.x API, and all of 3.x should co-exist in
the same class loader.
-- An alternative if we are not breaking binary compatibility, is to keep
improving 2.x.
- If I only care about plugin A and B, I can run 'mvn -pl pluginA,pluginB';
if I do that all day, I can create a Maven profile.
- I don't care if Dependabot tells me there is a new version of the API or
this or that module, even if it has not changed aside from the version.
Because: I am confident that everything that has the same version works
together.
- I don't care about JPMS, it is something I workaround, not use.
- We should implement JPMS in the least intrusive manner, for example,
using the Maven Moditect plugin (FWIW, this the path we took in Apache
Commons, which generates all module-info files).

"Excessive testing time
Tests of irrelevant modules (e.g., `log4j-osgi`) are taking too much time,
hence developers grow to commit without `./mvnw verify`, which eventually
is breaking the build."

If a commit breaks the product, then it's the dev's fault, no matter how
you slice and dice the code in one or ten repos.
Today in 2.x, I can run 'mvn -pl A,B,C' if I think my changes only affect
A,B,C. It's my fault if I break the product's D,E,F modules.
In a multi-repo, I still have to run one or more builds, and it's still my
fault if I break the product except that now I have repos all over the
place to think about.
So this is akin to the old joke from my C days "Dev1: Look, I made it
faster! Dev2: Yeah, it crashes so much faster for me now", except that now,
you don't even know you broke something. I know, CI-builds.

"Many modules (Jackson-based layouts, JNDI, Liquibase, etc.) are supposed
to be dead, long ago. Developers want them to be abandoned, though this
conflicts with our backward-compatibility promises in a major release."
You must mean *within* a major release line and not in a new major release.
Otherwise: That's the point of a major release! It's the only time you're
allowed to break binary and source compatibility. We have different
expectations of what a major release means.

Gary

On Wed, Aug 30, 2023 at 9:05 AM Volkan Yazıcı <vol...@yazi.ci> wrote:

> I have been collecting information and input for splitting the
> `logging-log4j2` repository into multiple projects. This can be achieved by
> either using the existing repository or migrating to a multi-repo setup. I
> have shared my findings in this Google Doc
> <
> https://docs.google.com/document/d/1BDCBbtXNe0UhvMAZs0kudSIGgX83duIA2It5PwIDATQ/edit
> >
> –
> anybody can view, PMC can edit.
>
> *This is a big change affecting every maintainer! Please check the document
> and share your feedback (questions, preference, etc.) in this thread.*
>
> *Notes*
>
>    1. Piotr and I will be full-time busy with implementing this for close
>    to a month starting from next Monday. Hence, I need your prompt
> feedback to
>    flesh a plan out.
>    2. After your feedback I will share the conclusive document in
>    Confluence and/or in GitHub Issues.
>

Reply via email to