Re: A heads-up about automated dependency updates (esp Resolver in Maven Plugins)

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 <[email protected]> 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
> <[email protected]> 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 <[email protected]> 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: [email protected]
> > > For additional commands, e-mail: [email protected]
> > >
> >
> >
> > --
> > Sławomir Jaranowski
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >