Re: Mono-vs-Multi repo setup

Hi all, On Sun, 3 Sept 2023 at 22:37, Ralph Goers wrote: > 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 w

Re: Mono-vs-Multi repo setup

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, p

Re: Mono-vs-Multi repo setup

Hi Gary, On Sat, 2 Sept 2023 at 14:36, Gary Gregory wrote: > So any time you release any jar, the BOM is updated? The current `log4j-bom` artifact should probably be released each time (or shortly after the last release if multiple releases are close together). However we can also introduce oth

Re: Mono-vs-Multi repo setup

I am not able to follow. Granted nobody is proposing an ossified BOM that is rarely released, mind explaining why would my statement be an argument against multi release cycles? Could you give an example of how multi release cycles funnelled through the release of a BOM project will disrupt the wo

Re: Mono-vs-Multi repo setup

On Sat, Sep 2, 2023 at 11:39 AM Volkan Yazıcı wrote: > Maybe, maybe not. PMC will decide on the release timing of the BOM. > Right, so maybe it's an argument in favor of your point or maybe it's an argument against! ;-) Gary > > On Sat, Sep 2, 2023 at 2:35 PM Gary Gregory > wrote: > > > On S

Re: Mono-vs-Multi repo setup

Maybe, maybe not. PMC will decide on the release timing of the BOM. On Sat, Sep 2, 2023 at 2:35 PM Gary Gregory wrote: > On Sat, Sep 2, 2023 at 6:45 AM Volkan Yazıcı wrote: > > > > For me, there is one kind of "user" > > > > As Piotr indicated we have multiple user groups. As stewards of this >

Re: Mono-vs-Multi repo setup

On Sat, Sep 2, 2023 at 6:45 AM Volkan Yazıcı wrote: > > For me, there is one kind of "user" > > As Piotr indicated we have multiple user groups. As stewards of this > project we should take these into account, not just our personal agenda. > The current release model where everything shipped all

Re: Mono-vs-Multi repo setup

On Sat, Sep 2, 2023 at 8:35 AM Gary Gregory wrote: > On Sat, Sep 2, 2023 at 6:45 AM Volkan Yazıcı wrote: > >> > For me, there is one kind of "user" >> >> As Piotr indicated we have multiple user groups. As stewards of this >> project we should take these into account, not just our personal agend

Re: Mono-vs-Multi repo setup

> For me, there is one kind of "user" As Piotr indicated we have multiple user groups. As stewards of this project we should take these into account, not just our personal agenda. The current release model where everything shipped all at once doesn't cater for all such use cases. > For me, there

Re: Mono-vs-Multi repo setup

Hi Herve, On Fri, 1 Sept 2023 at 09:10, Herve Boutemy wrote: > > it's not "mono vs multi (Git) repo setup" but "monolithic vs > component-oriented release" Thanks for putting the discussion back on track. I think we could look at what other logging frameworks do. Ceki's SLF4J/Logback has: * o

Re: Mono-vs-Multi repo setup

Hi Piotr, Thank you for your detailed response :-) My comments are inline below. On Thu, Aug 31, 2023 at 4:59 PM Piotr P. Karwasz wrote: > Hi Gary, > > May I offer a different perspective on this. > I knew that ;) > > On Wed, 30 Aug 2023 at 18:56, Gary Gregory wrote: > > - I like a mon-re

Re: Mono-vs-Multi repo setup

Hi all, I agree that the discussion should have been framed differently. It immediately reminds me of a headache I never have: To pick up a new version of Jetty, I just update a property in my POM. That's all I need to pick up the 170 modules Jetty provides (not sure how many are jars). I know it'

Re: Mono-vs-Multi repo setup

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

Re: Mono-vs-Multi repo setup

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 co

Re: Mono-vs-Multi repo setup

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 depend

Re: Mono-vs-Multi repo setup

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

Re: Mono-vs-Multi repo setup

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

Mono-vs-Multi repo setup

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