The difference of "premature" and wrong optimization by skipper can be seen on tree: https://gist.github.com/cstamas/2c9af92c8c86ad9dae3913a06200b395
So most probably this will need to be handled automatically in Maven, but so far I exposed only knobs and let user combine them to experiment... T On Thu, Oct 23, 2025 at 11:25 AM Tamás Cservenák <[email protected]> wrote: > > 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]
