Howdy, as long as your code "play by the rules" (as explained here): https://maven.apache.org/resolver/api-compatibility.html we guarantee you binary compatibility when using resolver within Maven.
That said, in your mojo you just inject the reposystem "as usual" (so as you say in your mail) and you should not worry about anything, the resolver 1.6 vs 1.9 change will not affect your Mojo. Longer story: Resolver is a bit "special" in this area, and for worse, things changed a bit more in 3.9.x (see "potentially breaking changes" https://maven.apache.org/docs/3.9.0/release-notes.html applicable to Maven 3.9.x). Before 3.9.x only resolver api, spi and impl was "exported" by maven (so whatever your plugin declared, was in reality ignored, and you got these classes from maven core), OTOH, the rest of resolver artifacts were left on plugins (!), so versions from plugin declared "came in play". This resulted that a plugin, that used resolver and declared resolver as (non-provided) dependency, ended up with classpath where versions of resolver artifacts (api, spi, impl coming from maven core, while the rest resolved from plugin POM) were usually MIXED. This was an even bigger problem when a Mojo opted to construct "its own Resolver instance" using various means (like deprecated ServiceLocator). The direct consequence of this situation was that the surface of Resolver (even the non public!) was "deeply frozen", to allow, or rather, be permissive for cases like this. It prevented really any change on the surface. This also resulted in cases where user bug reports were hard if not impossible to reproduce (as they stemmed from specific maven version + plugin resolver version combinations, weird stuff, etc). Moreover, Resolver 1.8 broke this binary compatibility (with the introduction of Checksum SPI https://maven.apache.org/resolver/about-checksums.html that allows "real" extensibility of checksums, instead of "just" exposing MessageDigest.getInstance method as before), affected resolver artifacts were spi, impl and connector, and out of these three the connector was "plugin realm" artifact, it came from plugin declared version, not maven core. Of course this resulted in breakage (Linkage errors etc). Hence, Maven 3.9.x makes itself "stricter", disallows "manual" construction of resolver within the realm of Mojos. All this to avoid runtime linking errors (so maven can guarantee "same version" used across resolver artifacts). In turn, resolver now explicitly declares "rules of game" on the "api compatibility" page, that we guarantee to consumers. All this above should affect nothing or very little for existing "resolver consuming mojos": you just inject a repoSystem and use it as before. But this may sound scary for some advanced use cases (example: you have a library that constructs and uses resolver, and you want to use that library within Mojo as well), but for those we provide solutions as well (but is off topic for this thread). On Sat, May 20, 2023 at 12:35 AM Henning Schmiedehausen < henn...@schmiedehausen.org> wrote: > Hi, > > The page on https://maven.apache.org/resolver/maven-3.8.x.html states > that *"Since > version 1.7.0, Maven Resolver requires Java 8 to run and a brand new > default sync context factory has been implemented."*. > > Assuming for a moment that Java 8+ is a no-brainer, what does the second > part of that sentence mean? If a plugin would require Java 8+ anyway (or > even Java 11+), would it be possible for a plugin to move past 1.6.x and > still be compatible with Maven 3.8.x or would using any version past 1.6.3 > (we are on 1.9.x now) not work with Maven 3.8? > > I have a plugin that has resolver api in "provided" scope so it will be > whatever maven will inject into the plugin and the implementation itself is > in compile scope (so it will be bundled with the plugin). > > Any pointer appreciated. > > -h >
