I like the idea of the intermediate 3.10.x version which is between 3.x and 4.x. This is a good practice to reduce the complexity of the migration to the major update of Maven 4. Few things I’d like to highlight: * it should be back compatible binary (the maven core artifacts; but resolver is a transitive artifact, so it’s not mandatory IMO) * it should be back compatible behaviorally with default settings
This means, e.g., that the new strict validation of the resolver prefix can be opt-in, but should be disabled by default. As a trade-off this may print warnings, but it should behave in a 3.x way (do not block the build). I mentioned this in the past, the pretty common enterprise settings.xml configuration which overrides global Maven central to an internal Artifactory host (which hosts both inner and global artifacts in one virtual repo) will simply not work. For this reason for any local experiments with Maven 4 I have to specify the flag -Daether.remoteRepositoryFilter.prefixes=false for builds. I know that this was called “a bad practice” and I don’t argue about that. I just would like to clarify it’s a common pattern for thousands of organizations and 3.10 should not break it (but may facilitate moving towards best practices). > On 16 Feb 2026, at 19:05, Tamás Cservenák <[email protected]> wrote: > > Howdy, > > I would like to declare the Resolver 1.x lineage "EOL" (of course, not > yet archived). We should keep doing only bug fixes that are declared a > "really must" from Maven 3.9.x perspective (if needed; if found such > ones). Resolver 1.9.x was in "bugfix maintenance" mode for over 2 > years now, declared as such on 25th September, 2023, see [1]. > > Resolver 2.x moves quickly, but maintaining two branches (1.x and > master) is getting more and more cumbersome and a waste. Maven 3.9.x > should be the last version of Maven 3.x that uses Resolver 1.x. > > At the same time, I'd like to pitch a new minor lineage of Maven: > 3.10.x, that would close the current 3.9.x branch and take over the > "stable" label. Maven 3.10.x could for start use Resolver 2.x, making > it on-par (aligned) with upcoming Maven 4.x as far as resolver > features go. See [2] for required changes, they are not big. I would > like to remind, that Resolver 2.x is Java 8 baseline (while it does > have some modules that are 11 or even 17, but those modules are not > mandatory modules). > > Of course, doing this would introduce breaking changes (on Resolver > APIs, available for example for Mojos), read [3] about them, but most > of them -- as regarding public surface like Resolver API, SPI and Util > are limited to removal of deprecated methods (deprecated in 1.9.x). A > healthy codebase should not have an issue with this change. > > Aside from that, Maven 3.10.x should/could receive some other > improvements as well, for example: > - user wide extensions -- something very useful for > - migrate off from plexus to inject > - there are some "parked" PRs already like settings/server aliases > - ? > > OTOH, things that FOR SURE cannot (and IMHO should not) "trickle down" > from Maven 4 to Maven 3.10,x are among other things, the > plexus-sec-dispatcher improvements, given they _require_ Java 17 (use > of Unix Domain Sockets, and while there is Java 8 lib for this, I'd > advise against bloating Maven Core). > > The goal is really to _unify_ Resolver in both "maintained" major > Maven versions, and stop wasting effort on maintaining old Resolver > 1.x. This will also ease aligning (from user perspective) several > configurations across Maven 3.10.x and Maven 4. > > WDYT? > > [1] https://lists.apache.org/thread/6mlh4xpny0knpqr1wn2zn20q0cgrh7ob > [2] > https://github.com/apache/maven/compare/maven-3.9.x...cstamas:maven:maven-3.9.x-resolver-2.x?expand=1 > [3] https://maven.apache.org/resolver/upgrading-resolver.html > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
