Was there a particular reason we skipped `release-2.x`? On Mon, May 30, 2022 at 4:44 PM 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? > >>>>>> > >>>>>> > >>>> > >> > >> > >
