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 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 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 feeli
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 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 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
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 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 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
Spotless is annoying
How is this possible now that we use spotless in 2.x: mvn clean install -pl log4j-api,log4j-core -DskipTests [INFO] [INFO] Reactor Summary for Apache Log4j API 2.20.1-SNAPSHOT: [INFO] [INFO] Apache Log4j API ... FAILURE [ 22.303 s] [INFO] Apache Log4j Core .. SKIPPED [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 25.370 s [INFO] Finished at: 2023-09-01T08:10:43-04:00 [INFO] [ERROR] Failed to execute goal com.diffplug.spotless:spotless-maven-plugin:2.30.0:check (default-spotless) on project log4j-api: The following files had format violations: [ERROR] src\main\java\org\apache\logging\log4j\internal\package-info.java [ERROR] @@ -1,20 +1,20 @@ [ERROR] -/*\r\n [ERROR] - * Licensed to the Apache Software Foundation (ASF) under one or more\r\n [ERROR] - * contributor license agreements. See the NOTICE file distributed with\r\n [ERROR] - * this work for additional information regarding copyright ownership.\r\n [ERROR] - * The ASF licenses this file to You under the Apache license, Version 2.0\r\n [ERROR] - * (the "License"); you may not use this file except in compliance with\r\n [ERROR] - * the License. You may obtain a copy of the License at\r\n [ERROR] - *\r\n [ERROR] - * http://www.apache.org/licenses/LICENSE-2.0\r\n [ERROR] - *\r\n [ERROR] - * Unless required by applicable law or agreed to in writing, software\r\n [ERROR] - * distributed under the License is distributed on an "AS IS" BASIS,\r\n [ERROR] - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.\r\n [ERROR] - * See the license for the specific language governing permissions and\r\n [ERROR] - * limitations under the license.\r\n [ERROR] - */\r\n [ERROR] -/**\r\n [ERROR] - * This package should be considered private.\r\n [ERROR] - */\r\n [ERROR] -package org.apache.logging.log4j.internal;\r\n [ERROR] +/*\n [ERROR] + * Licensed to the Apache Software Foundation (ASF) under one or more\n [ERROR] + * contributor license agreements. See the NOTICE file distributed with\n [ERROR] + * this work for additional information regarding copyright ownership.\n [ERROR] + * The ASF licenses this file to You under the Apache license, Version 2.0\n [ERROR] + * (the "License"); you may not use this file except in compliance with\n [ERROR] + * the License. You may obtain a copy of the License at\n [ERROR] + *\n [ERROR] + * http://www.apache.org/licenses/LICENSE-2.0\n [ERROR] + *\n [ERROR] + * Unless required by applicable law or agreed to in writing, software\n [ERROR] + * distributed under the License is distributed on an "AS IS" BASIS,\n [ERROR] + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.\n [ERROR] + * See the license for the specific language governing permissions and\n [ERROR] + * limitations under the license.\n [ERROR] + */\n [ERROR] +/**\n [ERROR] + * This package should be considered private.\n [ERROR] + */\n [ERROR] +package org.apache.logging.log4j.internal;\n [ERROR] src\main\java\org\apache\logging\log4j\message\package-info.java [ERROR] @@ -1,21 +1,21 @@ [ERROR] -/*\r\n [ERROR] - * Licensed to the Apache Software Foundation (ASF) under one or more\r\n [ERROR] - * contributor license agreements. See the NOTICE file distributed with\r\n [ERROR] - * this work for additional information regarding copyright ownership.\r\n [ERROR] - * The ASF licenses this file to You under the Apache license, Version 2.0\r\n [ERROR] - * (the "License"); you may not use this file except in compliance with\r\n [ERROR] ... (36 more lines that didn't fit) [ERROR] Violations also present in: [ERROR] src\main\java\org\apache\logging\log4j\package-info.java [ERROR] src\main\java\org\apache\logging\log4j\simple\package-info.java [ERROR] src\main\java\org\apache\logging\log4j\spi\package-info.java [ERROR] src\main\java\org\apache\logging\log4j\status\package-info.java [ERROR] src\main\java\org\apache\logging\log4j\util\package-info.java [ERROR] Run 'mvn spotless:apply' to fix these violations. [ERROR] -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and
Re: Spotless is annoying
Hi Gary, On Fri, 1 Sept 2023 at 14:19, Gary D. Gregory wrote: > > How is this possible now that we use spotless in 2.x: It's a CRLF vs LF problem. About 6 months ago[1] I added a `.gitattributes` file[2] that forces line endings as LF also on Windows. This should solve two problems: * approach the goal of reproducibility on **any** OS with an OpenJDK compiler; some Maven plugins may still use system-dependent line endings, but most of the files should be Ok, * allow Spotless to work without Git (line endings are configured as UNIX instead of the default "ask Git"). Git should take care of line endings after the file "is touched by Git" (whatever that means). Usually a: git add --renormalize * helps. Another possibility is that Eclipse reconverts the line endings to CRLF. Piotr [1] https://lists.apache.org/thread/bvt8s71gf2k2g5lhy5sbf20xtcpvvbbo [2] https://github.com/apache/logging-log4j2/blob/2.x/.gitattributes
Re: Spotless is annoying
Ah! Excellent news, I'll give it a go. Gary On Fri, Sep 1, 2023, 11:21 AM Piotr P. Karwasz wrote: > Hi Gary, > > On Fri, 1 Sept 2023 at 14:19, Gary D. Gregory wrote: > > > > How is this possible now that we use spotless in 2.x: > > It's a CRLF vs LF problem. About 6 months ago[1] I added a > `.gitattributes` file[2] that forces line endings as LF also on > Windows. This should solve two problems: > * approach the goal of reproducibility on **any** OS with an OpenJDK > compiler; some Maven plugins may still use system-dependent line > endings, but most of the files should be Ok, > * allow Spotless to work without Git (line endings are configured as > UNIX instead of the default "ask Git"). > > Git should take care of line endings after the file "is touched by > Git" (whatever that means). Usually a: > > git add --renormalize * > > helps. Another possibility is that Eclipse reconverts the line endings to > CRLF. > > Piotr > > [1] https://lists.apache.org/thread/bvt8s71gf2k2g5lhy5sbf20xtcpvvbbo > [2] https://github.com/apache/logging-log4j2/blob/2.x/.gitattributes >
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's all designed to work together, unlike the dice roll proposed with scattered component releases. ActiveMQ is another example that comes to mind. Gary On Fri, Sep 1, 2023, 3:10 AM 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 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. >
Re: Spotless is annoying
That did not help but this sure does: -Dspotless.check.skip=true Gary On Fri, Sep 1, 2023 at 1:29 PM Gary Gregory wrote: > Ah! Excellent news, I'll give it a go. > > Gary > > On Fri, Sep 1, 2023, 11:21 AM Piotr P. Karwasz > wrote: > >> Hi Gary, >> >> On Fri, 1 Sept 2023 at 14:19, Gary D. Gregory >> wrote: >> > >> > How is this possible now that we use spotless in 2.x: >> >> It's a CRLF vs LF problem. About 6 months ago[1] I added a >> `.gitattributes` file[2] that forces line endings as LF also on >> Windows. This should solve two problems: >> * approach the goal of reproducibility on **any** OS with an OpenJDK >> compiler; some Maven plugins may still use system-dependent line >> endings, but most of the files should be Ok, >> * allow Spotless to work without Git (line endings are configured as >> UNIX instead of the default "ask Git"). >> >> Git should take care of line endings after the file "is touched by >> Git" (whatever that means). Usually a: >> >> git add --renormalize * >> >> helps. Another possibility is that Eclipse reconverts the line endings to >> CRLF. >> >> Piotr >> >> [1] https://lists.apache.org/thread/bvt8s71gf2k2g5lhy5sbf20xtcpvvbbo >> [2] https://github.com/apache/logging-log4j2/blob/2.x/.gitattributes >> >
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-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. > I don't think this is relevant IMO. For me, there is one kind of "user": a POM that Dependabot can optionally manage. Over at Apache Commons, Dependabot runs on Friday and that's the day I pay attention to such things (or Saturday AM). Running it every day is not great. It would be nice if Dependabot could tell you about releases that address CVEs as soon as they are available. > > > -- 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. > That's bad in my view, it's confusing as well. > > > -- 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. > Maybe, maybe not. What module is in what repo is imaginary ATM. > 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`. > "With some improvements to Dependabot..." is an argument against what you propose. You can't sell me something built with a tool that doesn't exist. > > -- 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. > And imagine the surprise when they break a downstream build they had no idea existed in the first place. > > - 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.). > Well, there's one thing we can agree on :-) > > > - 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". Giving it a more polite name does not change anything. I see three states: Supported, Deprecated, and Removed. I'll stop here since I've already expressed my arguments against what's below. Gary > 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 ye
