The subset project execution hangs (specified via "-pl" parameter) I've created an issue with some details https://github.com/apache/maven/issues/11302 (IMO blocker) If I'm not mistaken, there were similar problems with Maven 3 that were eventually addressed.
On Mon, Oct 20, 2025 at 1:29 PM Sergey Chernov <[email protected]> wrote: > 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 >> >
