Howdy, so for quick turnaround, I did this: https://github.com/maveniverse/maven-boms
This project uses Nisse + BOM builder and publishes 3 BOMs for given Maven version: * "fat" that is "full stack" * "skinny" that is "reactor only" * "plugin" that is BOM meant for Maven plugins [1] I deployed snapshots for them here: Fat BOM https://central.sonatype.com/repository/maven-snapshots/eu/maveniverse/maven/maven-boms/fat/3.9.11-01-SNAPSHOT/fat-3.9.11-01-20250823.164534-1.pom Skinny BOM https://central.sonatype.com/repository/maven-snapshots/eu/maveniverse/maven/maven-boms/skinny/3.9.11-01-SNAPSHOT/skinny-3.9.11-01-20250823.164534-1.pom Plugin BOM https://central.sonatype.com/repository/maven-snapshots/eu/maveniverse/maven/maven-boms/plugin/3.9.11-01-SNAPSHOT/plugin-3.9.11-01-20250823.164534-1.pom Please inspect them! And please ping back with your findings. [1] The plugin BOM was defined here: https://github.com/apache/maven/pull/689#issuecomment-1223881456 In other words, "plugin" BOM defines versions for those dependencies that a Maven Plugin cannot override at runtime. Thanks T On Sat, Aug 23, 2025 at 2:52 PM Sylwester Lachiewicz <slachiew...@gmail.com> wrote: > > 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 > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
