1. > This has been fixed a few months ago. > See https://github.com/apache/maven-wrapper/pull/335 > You need to update your wrapper scripts, the problem is not in maven itself.
Indeed, after updating to Maven Wrapper to 3.3.4 the problem is gone, thanks. Also I see the beta-5 is available on maven central /4.0.0-beta-5/apache-maven-4.0.0-beta-5-bin.zip > --- > Caused by: org.eclipse.aether.resolution.DependencyResolutionException: The > following artifacts could not be resolved: > com.acme:maven-custom-extension:jar:v0.0.5-alpha1 (absent): Prefix > > com/acme/maven-custom-extension/v0.0.5-alpha1/maven-custom- extension-v0.0.5-alpha1.jar > NOT allowed from central ( > https://registry.acme.com:443/registry/java-registry <https://registry.acme.com/registry/java-registry>, default, > releases+snapshots) > Those exceptions are a shortcut to avoid unnecessary HTTP requests to the repository > which is known to not have a given groupId. > More information could be interesting to investigate, but this is not > supposed to change the outcome. How the Maven makes a decision which groupId are available and which are not, as the repository configuration looks like this in `settings.xml`: ``` <repositories> <repository> <snapshots> <enabled>false</enabled> </snapshots> <id>central</id> <name>java-virtual</name> <url>https://registry.acme.com:443/java-registry</url> </repository> <repository> <snapshots /> <id>snapshots</id> <name>java-virtual</name> <url>https://registry.acme.com:443/java-registry</url> </repository> </repositories> ``` (similar for pluginRepositories). There are no explicitly specified wildcards which groupIds are allowed and which are not. So I'd expect the old behavior is preserved iterating all known registries. Can you please elaborate more on this new changed logic of artifact resolving. Is there any migration instruction related? Or which exact details I can share to help discover this? 5. > You can disable it using `-Dmaven.consumer.pom=false`. Thanks. I assumed that's the bottleneck of the build, but it's still slow. For comparison, for the monolith project with 1000 modules (monolith = it's assembled to a single Docker artifact) with empty "target" directories and all resolved .m2 artifacts: `mvn3 clean` takes 2 sec, while `mvn4 clean` takes 34 seconds (it builds the model slowly). The build of this project (with all artifacts already downloaded) is about twice longer (mvn3 - almost 3 min, mvn4 - almost 7 min). I don't think it's a blocker for releasing Maven 4, but a reason for us to stay on Maven 3 at least for now. On Fri, Oct 17, 2025 at 7:52 AM Guillaume Nodet <[email protected]> wrote: > Le jeu. 16 oct. 2025 à 11:48, Sergey Chernov <[email protected]> a > écrit : > > > 1. > > > We have nightly builds available at > > > > > > > > https://repository.apache.org/content/repositories/snapshots/org/apache/maven/apache-maven/4.0.0-SNAPSHOT/ > > > > If such URL is specified in the maven-wrapper.properties > > ``` > > distributionUrl= > > > > > https://repository.apache.org/content/repositories/snapshots/org/apache/maven/apache-maven/4.0.0-SNAPSHOT/apache-maven-4.0.0-20251016.072157-103-bin.zip > > ``` > > > > the build fails with > > ``` > > ./mvnw -v > > ./mvnw: line 255: > > > > > /var/folders/99/834q4py50zn519q_2pqxy70w0000gn/T/tmp.QyIoZkCD8H/apache-maven-4.0.0-20251016.072157-103/mvnw.url: > > No such file or directory > > ``` > > This was already discussed. So I'd like to request to fix this before the > > release. It will simplify testing a lot in CI/CD environments (as you > just > > need to change the URL instead of cloning the maven repo, switching to > > correct branch which is not master BTW, calling version:set, making a > build > > and uploading to your local registry). Please consider this if you'd like > > to increase the early adoption of release candidates (any simple > impediment > > reduces it drastically). > > > > This has been fixed a few months ago. > See https://github.com/apache/maven-wrapper/pull/335 > You need to update your wrapper scripts, the problem is not in maven > itself. > > > > > > Alternatively (also) it could be great to release rc5 which can be easily > > used in mvnw. As there were many changes since rc4. > > > > 2. I tested fresh 4.0.x maven with several projects locally, including > > those which have custom plugins as well as lots of modules (1000). > > Great news, fresh version are significantly faster after these problems > > were addressed (thanks Tamas and everybody who contributed there). > > But please note that the build is still slower ~45-60%. This is not > > critical but may be a reason not to switch to 4.0.0 release right now for > > us. > > I believe the biggest bottleneck is aggregating flat list of transitive > > dependencies (see paragraph 5 below about listing transitive/direct > > dependencies). > > > > See below. > > > > 3. If all dependencies are downloaded, build is fine. But there are build > > failures related to resolving artifacts with a very misleading message > like > > (note that the real dependency name is a bit different as it's private): > > ``` > > Caused by: org.eclipse.aether.transfer.ArtifactFilteredOutException: > Prefix > > > > > com/acme/maven-custom-extension/v0.0.5-alpha1/maven-custom-extension-v0.0.5-alpha1.jar > > NOT allowed from central ( > > https://registry.acme.com:443/registry/java-registry, default, releases) > > at > > > > > org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:267) > > at > > > > > org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:201) > > at > > > > > org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:298) > > --- > > Caused by: org.eclipse.aether.resolution.DependencyResolutionException: > The > > following artifacts could not be resolved: > > com.acme:maven-custom-extension:jar:v0.0.5-alpha1 (absent): Prefix > > > > > com/acme/maven-custom-extension/v0.0.5-alpha1/maven-custom-extension-v0.0.5-alpha1.jar > > NOT allowed from central ( > > https://registry.acme.com:443/registry/java-registry, default, > > releases+snapshots) > > at > > > > > org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:311) > > at > > > > > org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolveInternal(DefaultPluginDependenciesResolver.java:268) > > ``` > > I could not fix this. What's the "filter", what's the "prefix", how is it > > configured? I checked the setting.xml schema 1.2.0 and could not find any > > relevant tags for it. I checked the Maven 4 release notes and could not > > find any related info. In the debugger I've found some dictionary with > > elements like > > ``` > > "commons-net" -> {Node@5994} "?commons-net" > > "jxta" -> {Node@5996} "?jxta" > > "excalibur-extension" -> {Node@5998} "?excalibur-extension" > > "directory-clients" -> {Node@6000} "?directory-clients" > > "easyconf" -> {Node@6002} "?easyconf" > > ... > > ``` > > which looks like a set of fraud dependencies (perhaps). The failure > message > > gives zero clarity on it. This may be a blocker for many projects. E.g. > for > > our codebase lots on internal dependencies are now blocked (not central > or > > fork and potentially fraud, but pure internal). Maybe I'm wrong and it's > > not fraud, but a version number with "alpha" in it or with versions based > > on the current timestamp. > > > > Those exceptions are a shortcut to avoid unnecessary HTTP requests to the > repository > which is known to not have a given groupId. > More information could be interesting to investigate, but this is not > supposed to > change the outcome. > > > > > 4. I'd like to run CI tests as well, but because of 3 I'm blocked. > > > > Well, as above... > > > > > > 5. AFAIK there is a brand-new conception of fat/thin POMs for > > export/deployment. And these "build" poms now list the plain list of all > > transitive dependencies. > > First: let's make it alphabetically sorted as it's not possible no > navigate > > thru the huge list of randomly ordered (probably it's a HashMap > iteration). > > Second: WDYT to opt-in old behavior for cases when I don't want a flat > > list? E.g. we have aggregating modules that refer to the other > aggregating > > modules. Imagine a composite spring-boot-starter listing all other > -starter > > modules. As a flat list it's immense and unreadable (some of our POMs are > > more than 100KB). In most scenarios this can be ok to use flat list by > > default, but if there is a choice to use old implementation and only list > > direct it would be awesome. > > > > The build POM is the one you write, which is deployed with a "-build" > classifier. > The consumer POM does not flatten the direct dependencies. But it flattens > the _managed_ dependencies which are _actually used_. The exact process > if the following: > > for each managed dep in the model: > * if there is no corresponding node in the tree, discard the managed dep > * if there's a direct dependency, apply the managed dependency to it > and discard the managed dep > * else keep the managed dep > > filter out direct dependencies which have a non-transitive scope > > remove managed dependencies which are direct dependencies > > That POM is not supposed to be user-friendly, but rather > computer-friendly. > > You can disable it using `-Dmaven.consumer.pom=false`. > > If your POM is 100 kB long, that's because you have a huge transitive graph > with lots of managed dependencies. You should not have more managed > dependencies in your consumer POM that the number of transitive > dependencies. > Reducing the size of the dependency tree of your artifacts can be a good > idea. > > On Thu, Oct 16, 2025 at 8:56 AM Arnaud Héritier <[email protected]> > wrote: > > > > > +1 > > > > > > Well done team > > > > > > Arnaud Héritier > > > GitHub/ASF/... : aheritier > > > > > > > > > On Wed, Oct 15, 2025 at 20:43 Guillaume Nodet <[email protected]> > wrote: > > > > > > > Hey everyone, > > > > > > > > We've fixed a ton of issues on the 4.0.x branch [1], so I think it’s > > time > > > > to cut the 4.0.0 release. > > > > Before that, I’d just like to get the Spotless/Palantir plugin > upgraded > > > [2] > > > > so that it works properly on JDK 17, 21, and 25 (we can later bump to > > the > > > > upcoming parent once it includes the same change). > > > > > > > > The release notes [1] currently only show the diffs since RC4, so we > > > should > > > > probably do another pass on the “What’s New in Maven 4” page [3] — to > > > > highlight the new mvnup upgrade tool (from rc-4) and double-check > that > > > > everything important is covered (if you see anything missing, please > > > yell). > > > > > > > > Any objections to this plan? If not, shall we go ahead? > > > > > > > > Cheers, > > > > Guillaume Nodet > > > > > > > > [1] > > > > > > > > > > https://github.com/apache/maven/releases/tag/untagged-269a18e49ead47082a92 > > > > [2] https://github.com/apache/maven/pull/11275 > > > > [3] https://maven.apache.org/whatsnewinmaven4.html > > > > > > > > > > > > -- > ------------------------ > Guillaume Nodet >
