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