Just for reference, here is a PR fixing the issue by setting up proper dependabot rules as well: https://github.com/ascopes/protobuf-maven-plugin/pull/773
T On Sat, Aug 23, 2025 at 11:56 AM Tamás Cservenák <ta...@cservenak.net> wrote: > > 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
