Howdy, some tooling already exists: gav-dm-tree: https://gist.github.com/cstamas/7e3f8d444a74d9a2f4f7d7114af156bf gav-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
