And it’s much simpler than moving the BOM around. Very nice! — Matt Sicker
> On May 30, 2022, at 09:44, Apache <[email protected]> wrote: > > It is implemented on master. > > Ralph > >> On May 30, 2022, at 2:27 AM, Volkan Yazıcı <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> 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ı <[email protected]> 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? >>>>>>> >>>>>>> >>>>> >>> >>> >
