Howdy, We have a thread about this on Slack, but let me just reiterate some things brought up there...
Here is what we could do, from "least helpful" to "most helpful" (for user PoV): 1. clearly document these, like "Maven 3 uses Resolver 1, and Maven 4 uses Resolver 2, do not mix the two...", similar to what site/doxia have: https://maven.apache.org/plugins/maven-site-plugin/history.html#maven-site-plugin-vs-doxia-vs-doxia-sitetools In this case, this would only indirectly help users, that could come to us once they hit the wall (breakage), and we can point them to doco, or they proactively find and obey this doco... 2. provide BOMs Maven 4 already provides them (two of them: "skinny" and "fat") while Maven 3 does not provide any. On a related note, in one early efforts for Maven 3 BOM that was closed out as we could not agree on "what BOM is", there was an interesting idea by Konrad: https://github.com/apache/maven/pull/689#issuecomment-1223881456 This would also mean we could/should create not only "maven BOM" (fat and skinny) but also "maven plugin BOM", that defines versions of (core provided) dependencies that a Maven plugin _cannot override_ (as they are provided to it by runtime). Still, this would again require user change: a project using packaging maven-plugin should be updated to use this maven-plugin-bom, but from that point on, smooth sailing... 3. something more... In general, we cannot figure out user intent when he goes from resolver 1.x to 2.x, but in certain cases we do have some hints: * packaging is maven-plugin (and major version of plugin tells, is it 3.x or 4.x) * use of maven-plugin-api is mandatory in these cases (unsure does packaging enforce this?) and it defines the version of it -- but this step may be redundant, as first step may be enough * the packaging/plugin-api implicitly defines the "platform", like maven 3.9.x * the platform defines major versions of dependencies as well, like resolver 1.x and slf4j 1.x etc So basically we may want a way to fail the build, if these divergences (for example by major version to not be so nitpicky) are detected? Third option would make all these plugins fail, once the user would update to a newer maven-plugin-plugin. Thanks T On Sat, Aug 23, 2025 at 11:37 AM Slawomir Jaranowski <s.jaranow...@gmail.com> wrote: > > We can add check for it in Maven validation - > https://maven.apache.org/guides/plugins/validation/ > > and also in plugin-tools ... > > On Fri, 22 Aug 2025 at 20:03, Tamás Cservenák <ta...@cservenak.net> wrote: > > > > Howdy, > > > > I was just checking downstream dependencies of Resolver 2.x and was > > first surprised how many of them are: > > https://deps.dev/maven/org.apache.maven.resolver%3Amaven-resolver-api/2.0.10/dependents > > > > By inspecting, I discovered that MANY are in fact Maven 3 plugins (!), > > building against some Maven 3.9.x version AND Resolver 2.0.x!!! > > > > By spot testing, I see these versions usually entered plugin projects > > via automated dependency updates that were "green" and then (blindly) > > merged. This is wrong! > > > > Resolver version in case Maven plugins should be kept in "lockstep" > > with Maven plugin is built against (as those artifacts are swapped out > > at runtime with runtime provided ones). This works based on the GA > > exported by Maven Core. Maven 3 uses Resolver 1, so exported GAs are > > based on Resolver 1.x, while Resolver 2.x introduces new artifacts but > > also things like transport renames (http -> apache, new jdk transport, > > etc). Basically, Resolver 2.x was NEVER meant to be used by Maven 3 > > plugins! > > > > Automated updates done by dependabot and alike _work_ as Resolver 2.x > > is strict regarding source and binary compatibility, see > > https://maven.apache.org/resolver/upgrading-resolver.html but this > > does not mean it is "right thing to do" (tm). > > > > Again, in case of Maven plugins major Maven dependencies usually need > > to be kept in "lockstep" (fx if you build against Maven 3.9.11 you > > should use Resolver 1.9.24). > > > > Maven 3 uses Resolver 1.x lineage, while Maven 4 uses Resolver 2.x lineage. > > > > Mixing two major versions should not happen! > > > > Thanks > > T > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > -- > Sławomir Jaranowski > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
