It is implemented on master. Ralph
> On May 30, 2022, at 2:27 AM, Volkan Yazıcı <vol...@yazi.ci> wrote: > > Mind somebody sharing the last state? Is it implemented, if so how and on > which branch(es)? Is it reverted? If so, totally or partially? > >> On Sun, May 29, 2022 at 9:53 AM Ralph Goers <ralph.go...@dslextreme.com> >> wrote: >> >> That is OK. I have reverted your commit and am testing the build for a >> second time doing it the correct way. >> >> Ralph >> >>>> On May 28, 2022, at 9:14 PM, Matt Sicker <boa...@gmail.com> wrote: >>> >>> It worked, but I had to specify where the parent pom was in the >> submodules. Are you saying I could get the same effect by importing the bom >> in the parent pom? If so, that certainly seems easier. >>> >>> — >>> Matt Sicker >>> >>>> On May 28, 2022, at 18:15, Ralph Goers <ralph.go...@dslextreme.com> >> wrote: >>>> >>>> Why is this necessary? I would think having the parent import the >> bom/pom.xml should be enough. >>>> >>>> Ralph >>>> >>>>> On May 27, 2022, at 6:18 PM, Matt Sicker <boa...@gmail.com> wrote: >>>>> >>>>> To avoid rearranging all the directories, I'm moving the parent pom to >>>>> its own directory, moving the bom pom to the root, and updating the >>>>> rest of the poms to know where the old parent pom now is. >>>>> >>>>>> On Thu, May 19, 2022 at 3:08 PM Matt Sicker <boa...@gmail.com> wrote: >>>>>> >>>>>> Agreed. I added the BOM POM later on and didn’t know of any >> established patterns for modules as BOMs weren’t used extensively quite yet >> at the time (and it was a Maven specific feature then, too; Spring ported >> the concept to Gradle later on, and now Gradle has a native concept of the >> same thing). >>>>>> >>>>>> — >>>>>> Matt Sicker >>>>>> >>>>>>> On May 19, 2022, at 10:33, Ralph Goers <ralph.go...@dslextreme.com> >> wrote: >>>>>> >>>>>> Yes, that would make sense. I am sure this happened simply because >> the bom pom.xml was introduced way after the first releases. >>>>>> >>>>>> Ralph >>>>>> >>>>>>> On May 18, 2022, at 11:38 PM, Volkan Yazıcı <vol...@yazi.ci> wrote: >>>>>> >>>>>> >>>>>> Even though we provide a BOM module (`log4j-bom`), we don't consume it >>>>>> >>>>>> ourselves. Hence occasionally we end up publishing artifacts not >> included >>>>>> >>>>>> in the BOM. Consuming our own BOM decreases the chances of missing out >>>>>> >>>>>> artifacts in BOM, though doesn't totally eliminate the chances of that >>>>>> >>>>>> happening. >>>>>> >>>>>> >>>>>> When I read how Maven advises to structure the BOM module >>>>>> >>>>>> < >> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#bill-of-materials-bom-poms >>> , >>>>>> >>>>>> I understand what needs to be in the case of Log4j is the following: >>>>>> >>>>>> >>>>>> /pom.xml (`log4j-bom` module) >>>>>> >>>>>> /log4j-parent/pom.xml (`log4j` module importing `log4j-bom`) >>>>>> >>>>>> /log4j-parent/log4j-core/pom.xml (`log4j-core` module parented by >> `log4j`) >>>>>> >>>>>> >>>>>> Though what we have in reality is the following: >>>>>> >>>>>> >>>>>> /log4j-bom/pom.xml (`log4j-bom` module) >>>>>> >>>>>> /pom.xml (`log4j` module parented by `logging-parent`) >>>>>> >>>>>> /log4j-core/pom.xml (`log4j-core` module parented by `log4j`) >>>>>> >>>>>> >>>>>> Ideally we should follow the Maven-advised approach and consume from >> our >>>>>> >>>>>> BOM parented by `logging-parent`. >>>>>> >>>>>> >>>>>> What do you think? Is my interpretation of the Maven-advised approach >>>>>> >>>>>> correct? >>>>>> >>>>>> >>>> >> >>
