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