Howdy Vladimir, SORRY, the proper command to make it work is this: ``` mvn verify -Daether.conflictResolver.versionSelector.selectionStrategy=highest -Daether.dependencyCollector.bf.skipper=versioned -pl example-application ```
In short, see here: https://github.com/apache/maven-resolver/pull/1565 Storytime: Maven originally had the "depth first" (DF) collector only, and we got donated later by EBay the "breadth first" (BF) collector that is _default_ in Maven 4 (in maven3 can be used by setting property). The working of BF is explained here: https://innovation.ebayinc.com/stories/open-source-contribution-new-maven-dependency-resolution-algorithm/ Given this collector was made for Maven 3, there was only "nearest" winner strategy, and the thing that makes new BF so good is in fact the "skipper" optimization, that fully skips subtrees if they were already collected somewhere else. But, alas, the skipper ALSO assumes "nearest" (is coded with that assumption). Hence, when using "highest", skipper interferes and cuts off subtrees that with highest MAY be selected, as in our case here. So I did a little change to skipper in Maven 4: logic to decide when to skip: "versionless" (GA) as default, works with "nearest" only, "versioned" (GAV) works with both, but if nearest used is sub-optimal and "false" (skipper is off). tl;dr: when using "highest" selection strategy one MUST use "versioned" skipper as well (or "false"), to not cut subtrees that may be selected. Again, all this is experimental, and we have many knobs and such things :) Thanks T On Thu, Oct 23, 2025 at 11:01 AM Vladimir Sitnikov <[email protected]> wrote: > > Just wondering: does mvnw verify work for you in the reproducer project? > > I tried ./mvnw verify > -Daether.conflictResolver.versionSelector.selectionStrategy=highest > and it results in NoClassDefFoundError: javax/inject/Provider > or NoClassDefFoundError: com/google/common/util/concurrent/SettableFuture > depending on the dependency order. > The error is different, however, the project still fails in the runtime. > > >as no direct deps override is expected > > I would like to discuss this after the main case (~ different versions > requested by transitives) is resolved. > > By the way, I just got bitten by this bug yesterday when preparing a smoke > test project for my day-to-day job. > Of course, I've added a workaround, however I would love Maven to resolve > the deps automatically: > https://github.com/Netcracker/qubership-core-base-images/pull/45/files#diff-2c51c07cc3e9dbc829b4a2ccef3b80894e1db355b5b2b1216ba0c970b21b7361R13-R21 > > Vladimir --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
