Looks like something that we should apply also to our 3.x branches for Maven projects
Sylwester sob., 23 sie 2025, 14:49 użytkownik Tamás Cservenák <ta...@cservenak.net> napisał: > 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 > >
