One more problem that I see in Maven 4. We have a custom Maven plugin *which is a part of the same reactor as modules* that declare goals from it. This works quite good in Maven 3, no need to distribute the plugin separately as a JAR dependency. Maven 4 fails to build the modules now with
> Error: Plugin platform.server.tools.maven:Plugin:2.BEX-MAVEN4.13264001 or > one of its dependencies could not be resolved: > Error: platform.server.tools.maven:Plugin:jar:2.BEX-MAVEN4.13264001 was > not found in https://registry.acme.com/registry/java-virtual during a > previous attempt. (you can notice that the Maven version is dynamic) Question: is it a bug (so I can provide more details, reproducing project) or it's by design not to allow this anymore? This approach has some disadvantages (like IDEA cannot properly import such a project the first time before you do a local mvn install), but it's quite convenient to have build plugins in the same codebase as modules that use it and build them together in one Maven command. It's somehow similar to Gradle buildSrc. On Sun, Nov 9, 2025 at 7:54 PM Sergey Chernov <[email protected]> wrote: > Howdy Sergey, >> Your env seems to have some issues. >> The "prefix" is part of Remote Repository Filtering (RRF >> https://maven.apache.org/resolver/remote-repository-filtering.html) >> feature added to Resolver 1.9.x and Maven 3.9.x. The "only" difference >> in Maven 4 is that it is enabled by default and is doing "auto >> discovery". > > > Hey, Tamas. Thank you very much for these clarifications, it helped a lot, > also was able to find these files under ~/.m2/repository/.meta > I fixed the problem with adding > -Daether.remoteRepositoryFilter.prefixes=false to .mvn/maven.config. > > Regarding the env issue. Indeed, my configuration has a ~/.m2/settings.xml > which is provided by our registry and this file looks like this: > <repository> > <snapshots> > <enabled>false</enabled> > </snapshots> > <id>central</id> > <name>java-virtual</name> > <url>https://registry.acme.com:443/artifactory/java-registry</url> > </repository> > > and this java-registry encloses several repositories including maven > central and locally hosted artifacts. For this reason our internal > artifacts were filtered. > > The problem here is that it's a classic configuration for enterprises > (I've seen this several times, so maybe it's even a dominating approach) > that restrict direct access to Maven Central. E.g. Artifactory has > solutions like X-Ray checking the vulnerable or scam dependency artifacts - > so these are just not downloadable from this proxy > registry, other registries may have similar features. The CI/CD > environments quite often don't have direct access to the internet and go > thru these registries. And the configuration instructions for local > environments (like engineer laptops) look simple: open Registry Settings, > generate keys, download settings.xml and save it under your .m2. > All of our backend engineers have this config. They do not edit these > files, just follow the standard instructions. > > What I mean is: once Maven 4 becomes a default distribution, all these > organizations are in trouble. This new feature is a good intention and I > understand the motivation behind this design. But there is a lack of > diagnostics on how to actually solve it. *The link > <https://maven.apache.org/resolver/remote-repository-filtering.html> that > you gave could be extremely helpful if it was printed by Maven itself > in the failure message.* > > I'd like to have some kind of seamless upgrade for our engineers which > will not require patching these local configurations. I tried to solve it > this way - add additional repository in the root parent pom of my project > with a name "acme" (not "central") having the same URL parameter - so all > our internal dependencies could be downloaded from it. But the build failed > fast, as it first downloads artifacts for .mvn/extensions.xml first > (which does not use these root pom declared repositories) - and these > extensions are internal, not published on the Maven Central. > > Also, just for the clarity. If a Maven proxy was a mistake, what's the > proper way to configure repositories to avoid downloading dependencies from > the Maven Central directly (which is not fine for many reasons)? Can you > please elaborate on that a bit more? Thanks in advance. > > > On Sun, Nov 9, 2025 at 3:57 PM Hervé Boutemy <[email protected]> > wrote: > >> +1 >> >> Reproducible Build checked ok: reference build done with Maven 3.9 and >> JDK 21 >> on *nix >> >> Regards, >> >> Hervé >> >> Le samedi 8 novembre 2025, 01:38:21 CET Guillaume Nodet a écrit : >> > Hi all, >> > >> > DISCLAIMER: >> > I accidentally published the distributions to the dist area instead of >> the >> > dev area. >> > If the vote is not successful, I'll ask infra to remove it... >> > >> > Draft release notes: >> > https://gist.github.com/gnodet/8a837a04a11f0e1359475c9dc5e68000 >> > >> > Staging repo: >> > https://repository.apache.org/content/repositories/maven-2339/ >> > >> https://repository.apache.org/content/repositories/maven-2339/org/apache/mav >> > en/apache-maven/4.0.0-rc-5/apache-maven-4.0.0-rc-5-src.zip >> > >> > Distribution staging area: >> > https://dist.apache.org/repos/dist/release/maven/maven-4/4.0.0-rc-5/ >> > >> > Staging site: >> > https://maven.apache.org/ref/4-LATEST/ >> > >> > Please review and vote ! >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >>
