Howdy, BOMs are "good things" when authored and used properly.
Problem begins when BOMs authors start adding import statements to their authored BOMs. BOMs should be _flat_. Problem explained: * I as consumer "delegate" dep control to library I want to use, BUT * library BOM "delegate" dep control to third library (those it imports) So I, as a consumer, am "two delegations away" from the problem(s) source. Is out of my reach. In a moment BOM contains import(s), it opens a possibility (does not have to!) of worms with conflicts, that are "non actionable warnings". Moreover, if my project needs two "recursive BOMs" for some reason, problems are just piling up. And to be no misunderstanding: NOTHING changed between Maven 3 and Maven 4 re "problem". The ONLY change in Maven 4 is that it is not silent anymore, it warns. And users cannot do anything about it, this is true for Maven 3 and Maven 4. Hence, to repeat my stance: personally, I'd never use these "problematic" BOMs in my projects, instead I'd "preprocess" them (flatten) as in that moment I (as consumer) am back in control: I can apply exclusions (in Maven 4), apply ordering and overrides I want, etc. T On Wed, Mar 19, 2025 at 1:46 PM Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > > Can we step back a sec, what does bom bring that is not solved without? > Dependency resolution is perfectly handled with type=pom (without > scope=import), reusability with multiple scope is quite trivial with a > property for the version and potentially the whole gav. > At the end we can forbid (= stop supporting) bom in v>4.0.0 poms IMHO. > > Romain Manni-Bucau > @rmannibucau <https://x.com/rmannibucau> | .NET Blog > <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | > Old > Blog <http://rmannibucau.wordpress.com> | Github > <https://github.com/rmannibucau> | LinkedIn > <https://www.linkedin.com/in/rmannibucau> | Book > <https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064> > > > Le mer. 19 mars 2025 à 11:51, Tamás Cservenák <ta...@cservenak.net> a > écrit : > > > Howdy, > > > > some tooling already exists: > > gav-dm-tree: > > https://gist.github.com/cstamas/7e3f8d444a74d9a2f4f7d7114af156bf > > gav-dm-list > > <https://gist.github.com/cstamas/7e3f8d444a74d9a2f4f7d7114af156bfgav-dm-list>: > > https://gist.github.com/cstamas/419f4663744150b76f737cbd89fedf4f > > and the new "flatten bom" mojo. > > > > And my proposal is to "pre-digest" the BOM, not any BOM you consume, > > just those super-BOMs that have deep (import) hierarchy (look at > > dm-tree and dm-list outputs above). > > While I did flatten-BOM, I was also tinkering to do some "merge" or > > alike, but realized that: > > * simple tool is better than complex > > * flatten "solves" the problem for big BOMs (for example, using this > > tool for Junit BOM makes no sense) > > * the rest of how to "fit" flattened BOM becomes simpler, as now that > > they are flat, you DO have control. > > * generation of flat BOM should be consistent: for same BOM GAV the > > output should be SAME -- just keep it simple; if we add knobs like > > which version to select, user could easily shoot himself in the foot > > > > The goal of new mojo is to flatten input BOM and do it consistently: > > if you point it at same BOM, your output is same as before (sans > > possible coordinate change of the emitted BOM itself) > > > > T > > > > On Wed, Mar 19, 2025 at 9:16 AM Hervé Boutemy <hbout...@apache.org> wrote: > > > > > > FTR Jira issues > > > https://issues.apache.org/jira/browse/MNG-7906 > > > https://issues.apache.org/jira/browse/MNG-7854 > > > https://issues.apache.org/jira/browse/MPH-183 > > > and all linked issues > > > > > > I don't know how this is relates with bom packaging in Maven 4 > > > > > https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Bill_of_Materials_.28BOM.29_POMs > > > > > > > > > The fact that this dependencyManagement import happens at effective model > > > building stage, and not during dependency resolution, created specific > > > complexity on how to analyze conflict resolution, report (not possible to > > > dependency-tree -Dverbose), and have solutions for end-user to override > > > default conflict resolution result. > > > > > > I dislike the currently non-actionable WARNINGs, particularly when > > actionable > > > solution when a conflict resolution does not bring you the result you > > want, you > > > can override by declaring a dependencyManagement entry before import. > > > > > > On what conflict resolution algorithm is in place, should we change it, > > to > > > which one: discussion never went to a solid proposition. > > > > > > Notice that we don't have great usable documentation on that feature and > > its > > > problems: just long discussions in Jira issues. > > > > > > I discover here what I'll call a new proposal from Tamasz: > > > 1. promote avoiding multiple conflicting dependencyManagement imports, > > as they > > > are hard to analyze > > > 2. promote a merging tool where these conflicts can be worked on and > > choices > > > done: first wins? last wins? (personal addition) greater wins? > > > I'm sure some reporting on BOM POMs could also be interesting, given they > > > started small and easy to get when used individually, but went complex > > when > > > people started to assemble them > > > > > > HTH > > > > > > Hervé > > > > > > Le mardi 18 mars 2025, 18:47:49 CET Tamás Cservenák a écrit : > > > > Howdy, > > > > > > > > Problem with BOM imports is that they were never "done done" in Maven > > > > 3.x time-frame, and they work the total opposite to everything else in > > > > Maven (think dependencies, as Delany says), hence they work in "non > > > > Maven way", not intuitive way, and tend to cause (usually bad) > > > > surprises. Sadly, they are overused in many projects, especially with > > > > recursive-imports happening. Maven 4 just tries to warn you about > > > > these, when a dependency is "stepping on toe" of another dependency, > > > > but again, as a consumer, you have not much control over it. > > > > Personally, I'd avoid using BOMs like these, and I'd preferably > > > > generate my own. > > > > > > > > In short, BOMs should be > > > > * flat (no recursive import) > > > > * generated > > > > * curated > > > > > > > > Sadly, with BOM you point at, none of these stands. Maven 4 tries to > > > > "fix" things, that's all. Same as with CI Friendly support, this is > > > > just yet another "incomplete" implementation. > > > > > > > > Personally, I'd prevent or better REMOVE recursive import capability > > > > (so dep type=pom scope=import would NOT recursively import anything) > > > > -- just to force them to be flat for start. > > > > BOMs should be curated and generated (and flat). > > > > > > > > For these cases: > > > > * take a peek at BOM generator (used in Maven build as well): > > > > https://github.com/maveniverse/bom-builder-maven-plugin > > > > * took a stab for a tool I'd use: BOM flatten, try it > > > > out!https://github.com/maveniverse/toolbox/pull/180 > > > > > > > > Regarding flatten-BOM: again, perso I'd NOT use BOM specified by you, > > > > but instead I'd deploy "flattened" BOM under my namespace (see gist > > > > example) and use that. Given it is generated, you can just generate > > > > new for any new version out there, > > > > > > > > > > > > My 5 cents > > > > T > > > > > > > > On Mon, Mar 17, 2025 at 8:43 PM Karl Heinz Marbaise > > > > > > > > <khmarba...@gmx.de.invalid> wrote: > > > > > Hi to all, > > > > > > > > > > currently I'm trying to build a simple spring boot application which > > > > > uses a BOM for spring-boot-dependencies.. > > > > > > > > > > <dependency> > > > > > > > > > > <groupId>org.springframework.boot</groupId> > > > > > <artifactId>spring-boot-dependencies</artifactId> > > > > > <version>3.3.3</version> > > > > > <scope>import</scope> > > > > > <type>pom</type> > > > > > > > > > > </dependency> > > > > > > > > > > So based on the releases of JUnit Jupiter, Mockito etc. > > > > > I define the BOM's of JUnit Jupiter and Mockito (and others; only > > > > > excerpts shown here) before the spring boot dependencies like this, > > > > > because I want to use newer versions, than spring-boot-dependencies > > > > > defines.> > > > > > <dependencyManagement> > > > > > > > > > > <dependencies> > > > > > > > > > > <dependency> > > > > > > > > > > <groupId>org.junit</groupId> > > > > > <artifactId>junit-bom</artifactId> > > > > > <version>5.12.1</version> > > > > > <type>pom</type> > > > > > <scope>import</scope> > > > > > > > > > > </dependency> > > > > > <dependency> > > > > > > > > > > <groupId>org.mockito</groupId> > > > > > <artifactId>mockito-bom</artifactId> > > > > > <version>5.16.1</version> > > > > > <scope>import</scope> > > > > > <type>pom</type> > > > > > > > > > > </dependency> > > > > > .. > > > > > <dependency> > > > > > > > > > > <groupId>org.springframework.boot</groupId> > > > > > <artifactId>spring-boot-dependencies</artifactId> > > > > > <version>${spring.boot.version}</version> > > > > > <scope>import</scope> > > > > > <type>pom</type> > > > > > > > > > > </dependency> > > > > > .. > > > > > > > > > > </dependencies> > > > > > > > > > > </dependencyManagement> > > > > > > > > > > If I build the project Maven 4.0.0-rc3 I got a bunch of warnings like > > > > > this: > > > > > mvn clean -e > > > > > [INFO] Error stacktraces are turned on. > > > > > [INFO] > > > > > ..... > > > > > [INFO] Scanning for projects... > > > > > [WARNING] > > > > > [WARNING] 26 problems were encountered while building the effective > > > > > model for 'com.soebes.spring.example:employee:jar:0.0.1-SNAPSHOT' > > (use > > > > > -e to see details) > > > > > [WARNING] Ignored POM import for: > > > > > org.assertj:assertj-core:jar:3.25.3@compile as already imported > > > > > org.assertj:assertj-core:jar:3.27.3@compile. Add the conflicting > > managed > > > > > dependency directly to the dependencyManagement section of the POM. > > > > > [WARNING] Ignored POM import for: > > > > > org.assertj:assertj-guava:jar:3.25.3@compile as already imported > > > > > org.assertj:assertj-guava:jar:3.27.3@compile. Add the conflicting > > > > > managed dependency directly to the dependencyManagement section of > > the > > > > > POM. > > > > > [WARNING] Ignored POM import for: > > > > > org.junit.jupiter:junit-jupiter:jar:5.10.3@compile as already > > imported > > > > > org.junit.jupiter:junit-jupiter:jar:5.12.1@compile. Add the > > conflicting > > > > > managed dependency directly to the dependencyManagement section of > > the > > > > > POM.... > > > > > > > > > > In Maven 3.9.9 I can build that project without any warning, because > > the > > > > > junit-bom is defined before the spring-boot-dependencies (which has > > > > > junit-bom on it's own in an older version), but overwrites the > > defined > > > > > in the spring-boot-dependencies with the newer versions, which is > > > > > exactly what I want.. > > > > > > > > > > Back to Maven 4: > > > > > So does that mean I have to add all the deps which are coming from > > the > > > > > junit-bom (also for the deps from assertj-bom, mockito-bom etc.) > > > > > manually into my dependencyManagement, as suggested? > > > > > > > > > > That will wipe away any advantage that using BOMs gives me. > > > > > > > > > > Is there a better solution which I'm not yet aware of? > > > > > > > > > > Kind regards > > > > > Karl Heinz Marbaise > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
