Le mer. 19 mars 2025 à 14:21, Thomas Reinhardt <tho...@reinhardt.com> a écrit :
> > If you need to digest a large 3rd party project you have to "know" all > the internal versions of that project and/or its dependencies in some way. > Any reason to that? It was cleanly handled before bom without any issues. > > For example we import com.fasterxml.jackson:jackson-parent which fixes > versions of about 60 artifacts. Of course we don't use all of those but > if we add e.g. some new transport mechanism, we are automatically > getting the correct version. In this case it is somehow easy, as those > versions are all (or at least most of them) the same. > This is what transitive dependencies are giving you and for sibling artifacts properties. I would even highlight it is dangerous to do it the way you mention cause in sibling modules you will inherit a version you do not want which overrides transitive dependencies and breaks your module. > > A more complex example is org.wildfly:wildfly-ejb-client-bom which > manages lots and lots of artifacts, all with different versions. > And it doesn't need bom, just type=pom. > > Arquillian is not even usable without > org.jboss.arquillian:arquillian-bom I think, because it would be > extremely time consuming to hunt down all the dependencies that you have > to have in the right versions because there were breaking changes. > It is perfectly and you do not have to hunt anything. Now, I can confirm using the bom breaks your project if you are using any competing dependency. > > Of course some of those are just symptoms of projects that arguably > should have been handled in a more simple way. But that is not the world > we are living in and we have to use what is out there. > > And honestly - I hate it when I have to use something with more than a > couple of artifacts and there is no bom. > > So with all due respect: please never even think about removing bom > support. It is an essential feature for any non-toy project. If anything > we (the maven users) need more support for boms. One thing that I am > always missing is some kind of information like "I need xyz-1.2.3.jar > and its dependencies, what are the coordinates for its bom". But I digress. > Don't get me wrong, I do not want to remove the hability to bring a full consistent stack of dependencies but the solution is not bom and exists since 10+ years in maven natively. > > > Thomas > > > > On 19/03/2025 13:43, Romain Manni-Bucau 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 > >
