And for future ref: https://maven.apache.org/resolver/configuration.html
Thanks T On Mon, 5 Oct 2026 at 16:20, Tamás Cservenák <[email protected]> wrote: > > Example invocation (on reproducer): > * reproducer did reproduce the issue okay for me > * https://gist.github.com/cstamas/02886cb7a557b066dab4dbf53f570c9a > > On Mon, 5 Oct 2026 at 16:17, Tamás Cservenák <[email protected]> wrote: > > > > Howdy, > > > > tl;dr: try these on CLI: > > -Daether.remoteRepositoryFilter.groupId=false > > -Daether.remoteRepositoryFilter.prefixes=false > > -Daether.artifactResolver.simpleLrmInterop > > > > So, you need to "dumbify" LRM (to "simple", the Maven2 level), BUT to > > achieve that, you need to shut down all of RRF too. So, to "workaround > > it", you have to intentionally give up some functionality. > > > > As you pointed out, the plugin does it wrong. > > > > HTH > > Tamas > > > > On Mon, 5 Oct 2026 at 15:37, Ryan Baxter <[email protected]> wrote: > > > > > > Hi, I have run into an issue with Maven 3.10.0 and I am unsure if this is > > > the right place to discuss the issue so please redirect me if I am not in > > > the right place. > > > > > > A plugin that resolves an artifact itself and passes an empty remote > > > repository list works on 3.9.x but not on 3.10.0 when the artifact is > > > already in the local repository. > > > > > > 3.10.0 reads _remote.repositories, sees the jar was cached from central, > > > finds that central is not in the (empty) repository list of the request, > > > and logs: > > > > > > Artifact org.jetbrains.kotlin:kotlin-maven-allopen:jar:1.6.21 is present > > > in > > > the local repository, but cached from a remote repository ID that is > > > unavailable in current build context, verifying that is downloadable from > > > [] > > > > > > The resolution then fails, and the plugin silently carries on without the > > > artifact. 3.9.16 returns the cached file for the same request. > > > > > > The real-world case is kotlin-maven-plugin 1.6.21 resolving > > > kotlin-maven-allopen for the all-open/spring compiler plugin. On 3.10.0 > > > the > > > jar never reaches the compiler's plugin classpath, the compiler plugin > > > does > > > nothing, and @Configuration classes stay final, so Spring Boot tests fail > > > with @Configuration class '...' may not be final. No error is logged for > > > the dropped plugin. > > > > > > The Kotlin plugin fixed this on its side in 1.9.0 (1.8.22 still fails, > > > 1.9.0 passes), but 1.6.x/1.7.x/1.8.x users can't get a fix, and many > > > projects pin those versions on maintenance branches. > > > > > > Is this an intended change? Is there any way we can get the old behavior > > > back? > > > > > > Here is a sample that will reproduce the issue: > > > https://github.com/ryanjbaxter/allopen-repo > > > > > > Thanks. > > > > > > -Ryan --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
