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. >
