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ı <vol...@yazi.ci> 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 <hbout...@apache.org> 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 <garydgreg...@gmail.com>
>> 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 because I use
>>>>> log4j-api v1, log4j-core v2, log4j-foo v3, log4j-bar v4, log4j-boo
>> v5,
>>>>> log4j-arg v6, and so on.
>>>>
>>>> If you stick to `log4j-api`, `log4j-bom`, `log4j-to-slf4j` or
>>>> `log4j-to-jul` above, you would also get just one Dependabot PR.
>>>> With some improvements to Dependabot, a new release of
>>>> `log4j-something` and `log4j-bom` might be ignored by Dependabot if it
>>>> detects that you are not using `log4j-something`.
>>>>
>>>>> -- 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 agree that finding the right repo in a multi-repo project might be
>>>> challenging.
>>>> On the other hand from a testing perspective the user does not have to
>>>> know why a PR on `log4j-core` starts a test suite in another repo.
>>>>
>>>>> - 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 would like that too in 3.x. At my current job the requirement was
>>>> "having a logging system that prints to a console or a file", so we
>>>> went with JUL. Of course I switched the backend on my dev box to Log4j
>>>> Core since debugging using JUL is painful (no proper layout, markers,
>>>> etc.).
>>>>
>>>>> - 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!"
>>>>
>>>> Let's use the term "to retire a module". These are feature stable that
>>>> have a much slower lifecycle than `log4j-core` and a smaller user
>>>> base.
>>>> I would prefer:
>>>> * to still support these modules,
>>>> * to have a version number that reflects the actual changes to the
>> module,
>>>> * to be able to release them independently if a bug report comes in,
>>>> * to allow people to relieve us from maintaining these modules, if
>>>> they work on a day-to-day basis with that technology. E.g. Apache
>>>> Cassandra might decide to take over `log4j-cassandra` (fork the repo).
>>>>
>>>> We are not talking about "hiding" them from the user: one of the
>>>> projects for next year is to include on our website the generated
>>>> documentation of every Log4j component that has an enhanced
>>>> `Log4jPlugins` in its JAR (on a opt-in basis).
>>>>
>>>> I have the feeling that we are discussing an X-Y problem: I want to be
>>>> able to release components independently, so I don't have to release
>>>> `log4j-core` just because SLF4J released version 2.x or I don't have
>>>> to delay the release of `log4j-core` because Jackson has a streak of
>>>> CVEs. I'd like to split the responsibility of releasing a 10M monthly
>>>> downloads product into more digestible bits.
>>>>
>>>> That is why I support multi-repo, because it seems simpler to reach
>>>> the goal. From a Public Relations perspective I would only like
>>>> `log4j-api` and the three existing implementations to have separate
>>>> repos.
>>>>
>>>> Piotr
>>>>
>>>
>>
