Here is my position on this.
1. We don’t change the repo layout for 2.x. It is too late in the game for
that as 2.x should be moving to maintenance mode.
2. Lpg4j API should be separated - both with its own repo and a separate web
site.
3. I would separate the rest as:
log4j2 - core, plugins, plugin-processor
log4j-jee - appserver, other JEE modules
log4j-api-bindings - modules that bind the LOG4J API to some other
implementation
log4j-core-bindings - modules that map some other API to Log4j API
and/or Core.
Log4j-jackson-layouts - Layouts that are implemented with Jackson
Other modules grouped as appropriate or as an individual artifact per
repo.
As I have also indicated, before splitting anything I would like a new repo
that contains integration tests for everything that relies on Log4j-Core Every
module that has a dependency on core should have a set of tests in this module
to ensure that all the components that make up a complete Log4j release can
cohabitate together. While we currently have tests for every module ew don’t
have anything that guarantees modules can be packaged tpgether in an
application.
Ralph
> On Sep 1, 2023, at 1:38 AM, Volkan Yazıcı wrote:
>
> Thanks for sharing your thoughts Herve, much appreciated!
>
> Completely agree with you that the discussion should have rather focused on
> the "monolithic vs component-oriented release" subject. Thanks for pointing
> this out! (I am partly to blame for not capturing the context right.)
>
> Regarding how to tackle website/documentation of multiple components with
> their own release cycles... Piotr and I have proposals (shared in private
> with the PMC) on that subject. But we first wanted to have a discussion and
> consensus on the "monolithic vs component-oriented release" subject, rather
> than adding one more variable to this intractable equation.
>
> On Fri, Sep 1, 2023 at 9:19 AM Herve Boutemy wrote:
>
>> additional notice: on implementing component-oriented approach
>>
>> from a tooling perspective, experience proves that the hard part is not at
>> Git level, but at generated Maven site level = how to replace a unique
>> Maven site for the monolithic release with a site that is a combination of
>> multiple components sites (each with their separate release documentation
>> history)
>>
>> On 2023/09/01 07:09:46 Herve Boutemy wrote:
>>> it's not "mono vs multi (Git) repo setup" but "monolithic vs
>> component-oriented release"
>>>
>>> longer explanation:
>>> IMHO, you should frame the discussion about:
>>> 1. keeping unique global/monolithic release of all log4j
>>> vs
>>> 2. splitting log4j into multiple parts/components released separately
>> (with dependency and compatibility expectations)
>>> = what is the real change
>>>
>>> at Git repo level, implementing the component-oriented strategy can be
>> done either from one unique Git repo or by multiple Git repos: there are
>> example of both in the wild, and IMHO the difference at Git level is not
>> really important
>>>
>>> what is important is to define which parts you'll want to release
>> separately as components
>>> then define how you'll explain the scope of these parts, and later their
>> versions and expected compatibility
>>> = this is where the opportunity is, but hard and impactful decisions
>> have to be made, and made clear to the whole community
>>>
>>> Regards,
>>>
>>> Hervé
>>>
>>> On 2023/08/31 20:59:32 "Piotr P. Karwasz" wrote:
Hi Gary,
May I offer a different perspective on this.
On Wed, 30 Aug 2023 at 18:56, Gary Gregory
>> wrote:
> - 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.
While seeing the same version is aesthetically pleasant, we have 4
kinds of users:
* library developers will never need anything beyond `log4j-api`,
* JUL users will only need `log4j-to-jul`, which declares its
`log4j-api` requirement,
* same for Logback users, they'll only need `log4j-to-slf4j`,
* Log4j Core users **need** to use `log4j-bom` anyway: I have seen
several question from Spring Boot users that add the newest version of
`log4j-core` to their app and end up with an old (incompatible)
version of `log4j-api`, since Spring Boot does version management.
> -- A mono-repo gives me the confidence that everything works
>> *together* because
> it was built and tested *together*.
In a multi-module setup we would still run e.g. `log4j-cassandra`
version 2.20.0 tests against the `log4j-core `2.24.0` snapshot.
> -- 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 becaus
