I'm quite interested in this conversation as in my experience the process of producing & consuming BOMs is still misunderstood.
Regarding 3rd party dependencies in a BOM, I've seen 2 main usages of BOMs. - library BOM: defines *only* those modules belonging to the same multi-project. Examples: https://github.com/oracle/oci-java-sdk/blob/master/bmc-bom/pom.xml https://github.com/oracle/helidon/blob/master/bom/pom.xml - stack BOM: defines both modules in the same multi-project build and 3rd party dependencies. This is the preferred way to distribute framework BOMs, such as Micronaut, Spring Boot, Helidon, etc. Examples: https://github.com/oracle/helidon/blob/master/dependencies/pom.xml Note the names "library" and "stack" are not official nor the official documentation makes explicit difference between them AFAICT. This is based on usage observation. Now, the docs do not mention BOMs should not have parents, do they? The Helidon BOM has a parent that defines publication & build-only concerns, no <dependencyManagement> nor <dependencies> https://github.com/oracle/helidon/blob/master/parent/pom.xml I think that's a valid usage. The oci-java-sdk parent POM OTOH not only defines <dependencyManagement> but also <dependencies>, thus forcing those dependencies into every child module if I'm not mistaken https://github.com/oracle/oci-java-sdk/blob/master/pom.xml BOMs are just POMs that must have <packaging>pom</packaging> and a <dependencyManagement> section (besides GAV coordinates); I believe every other valid POM element may or may not be applied however the PomChecker rules go beyond that and ban a few extra elements https://github.com/kordamp/pomchecker/blob/master/pomchecker-core/src/main/java/org/kordamp/maven/checker/BomChecker.java All this being said, the rules for crafting BOMs are still unclear to me, happy to be corrected and help clear them out :-) Cheers, Andres ------------------------------------------- Java Champion; Groovy Enthusiast http://andresalmiray.com http://www.linkedin.com/in/aalmiray -- What goes up, must come down. Ask any system administrator. There are 10 types of people in the world: Those who understand binary, and those who don't. To understand recursion, we must first understand recursion. On Thu, Feb 4, 2021 at 8:37 AM Thomas Broyer <t.bro...@gmail.com> wrote: > Actually, I'd say those BOMs probably shouldn't declare jackson. The > project's dependencies should be enough, and you explicitly declare the > version you need/want to use. > In the case of the OCI BOM, it seems quite clear that it mistakenly > inherits dependency management from it's parent POM: most BOMs shouldn't > have a parent, or their parent shouldn't include dependency management for > their submodules. > > Le jeu. 4 févr. 2021 à 00:56, Rupert Madden-Abbott < > rupert.madden.abb...@gmail.com> a écrit : > > > Hi, > > > > I have the following structure in my pom: > > > > My pom <- import oci-java-sdk-bom <- parent = ocj-java-sdk > > ^ > > | > > parent = spring-boot-starter-parent > > ^ > > | > > parent = spring-boot-dependencies <- import jackson-bom > > > > > > Both jackson-bom and oci-java-sdk have a dependency management section > and > > declare jackson-databind and I am also using this dependency in my > pom.xml > > without specifying a version. > > > > I have found that the version from oci-java-sdk is used and not the > version > > from jackson-bom (via spring boot). I naively expected that anything > pulled > > in from my pom's parent would instead take precedence. > > > > Why is this? Is it because the oci-java-sdk is 2 hops from my pom and the > > jackson-bom is 3 hops? Is there anything I can do to control this such > that > > the versions defined in my parent "win"? > > > > Where are these rules documented so I can work this out for myself in the > > future? > > > > Are there any tools/plugins that can help say why a given version has > been > > selected? > > >
