Le mer. 19 mars 2025 à 13:59, Tamás Cservenák <ta...@cservenak.net> a écrit :
> Howdy, > > BOMs are "good things" when authored and used properly. > > Not really, it is if you have a single one but as soon as it needs 3rd party it is a mess even if well written or you need a bom for all project and flatten all your dependencies in dependencies management. So I really think it was a good bad idea, we can just assume it now and deprecate the concept thanks to pom versions IMHO. > 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 > >
