>
> 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]
>
>
