Maven 4 hangs indefinitely on certain projects that build in seconds with Maven 3

[gnodet]

Description

When testing ~966 Apache projects against Maven 4.0.0-rc-5 (via gnodet/maven4-testing), 24 projects hang indefinitely under Maven 4 while building normally (30–600s) with Maven 3.

All builds use clean package -DskipTests — no tests are involved. The timeout is set to 1 hour, which should be more than sufficient for compilation-only builds.

Evidence

Project	Maven 3 Duration	Maven 4 Duration	Notes
karaf-minho	52s	3605s (killed)	Only on module 4/19 when killed
dubbo-integration-cases	48s	3605s (killed)
james-jspf	31s	3606s (killed)
mina-ftpserver	35s	3607s (killed)
sling-kickstart-maven-plugin	29s	3605s (killed)
qpid-proton-j	29s	3605s (killed)
aries-containers	33s	3604s (killed)
jclouds	125s	3606s (killed)
tinkerpop	343s	3607s (killed)	Only on module 2/28 when killed
cloudstack	673s	3613s (killed)

All 24 affected projects: aries-cdi, aries-containers, camel-kafka-connector, cloudstack, dubbo-integration-cases, incubator-nemo, incubator-nlpcraft-java-client, james-jspf, jclouds, karaf-minho, karaf-winegrower, mina-ftpserver, netbeans-html4j, qpid-proton-j, rocketmq-eventbridge, shenyu, sling-jspc-maven-plugin, sling-kickstart-maven-plugin, sling-org-apache-sling-kickstart, sling-slingstart-maven-plugin, streams, synapse, systemds, tinkerpop

Behavior

Maven 4 appears to hang (or run orders of magnitude slower) during early phases — likely dependency resolution or reactor setup. For example, karaf-minho (19 modules, 52s with Maven 3) is still compiling module 4 when killed at 1 hour.

This is NOT a timeout-too-short issue. Projects that compile in 30 seconds with Maven 3 should not need more than a few minutes with Maven 4.

Build command

mvn -V -B -e clean package -DskipTests -Drat.skip=true -Dmaven.javadoc.skip=true -Dcheckstyle.skip=true

Maven version: 4.0.0-rc-5

Summary issue

Full test run results: gnodet/maven4-testing#9485

[gnodet]

Root Cause Analysis

I investigated this hang and traced it to a cross-thread deadlock in AbstractRequestCache.requests() — the batch request caching mechanism used during dependency resolution.

The deadlock mechanism (in rc-5)

1. Thread A calls requests([artifactA, sharedDep]) — creates CachingSupplier instances and stores them in the cache (SoftIdentityMap)
2. Thread B calls requests([artifactB, sharedDep]) — gets back the same CachingSupplier for sharedDep because SoftIdentityMap used equals() (despite "Identity" in the name)
3. Thread B enters CachingSupplier.apply() for sharedDep, hits the individualSupplier lambda which does synchronized(nonCachedResults) { wait() } — waiting for Thread A's IdentityHashMap
4. Thread A's batch supplier completes and tries to populate results, but Thread B holds the CachingSupplier's monitor (via synchronized(this) in apply())
5. Permanent deadlock: Thread A can't deliver the result, Thread B can't receive it

Fix already on master

This was already fixed in commit c6de104 (#12446) which replaced the individualSupplier + IdentityHashMap wait pattern with:

• CachingSupplier.complete() — directly sets the value and calls notifyAll(), no external map needed
• ThreadLocal re-entrancy guard — prevents same-thread deadlocks when batch resolution triggers nested calls (e.g., parent POM resolution)
• singleSupplier fallback — re-entrant calls resolve individually instead of waiting

Regression test

I've added a specific cross-thread deadlock regression test in #12478 that reproduces the exact scenario: two threads calling requests() with overlapping keys through a shared equals-based cache, using a CyclicBarrier to force concurrent execution. This test would deadlock on rc-5 code but passes on master.