Maybe im missing something but why split repo cant be the solution of both without inventing 3 solutions? It works in all cases by design IMO and doesn't shout us making local repo dirty for all existing projects.
Only drawback I see if that it can need some enchantement to converge both worktree (scm aware) and project local (hygiène) but both are very easy to solve with a single clean convergence solution for all cases. Romain Manni-Bucau @rmannibucau <https://x.com/rmannibucau> | .NET Blog <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064> Javaccino <https://javaccino.dev/> founder (Java/.NET service - contact via linkedin) Le mar. 4 août 2026, 22:56, Guillaume Nodet <[email protected]> a écrit : > I don't think "isolation" is the right framing here. The question is > simpler than that. > > mvn verify and mvn package are supported lifecycle invocations in Maven. > They work for single-module projects. They're supposed to work for > multi-module projects too — and they do, thanks to project-local-repo and > the ReactorReader. That mechanism was added (MNG-7629) precisely to make > the reactor resolve cross-module artifacts during builds that don't run > install. > > So we have a supported feature that has a race condition. The fix is > straightforward: move the directory out of the blast radius of clean. > That's what PR #12650 does. > > The alternative is to say: "actually, mvn package and mvn verify are not > supported for multi-module builds — you must always run mvn install." > That's a valid position, but it's a breaking change in semantics that needs > a proper discussion, a deprecation path, and clear documentation. We can't > just leave the race condition unfixed and tell users to install an > extension. > > If we want install to be the only goal people should use, we should make > that explicit. We could drop the mvn compile reactor support too (since > it's broken for the same reasons), make clean an option rather than a goal, > and simplify the user experience to just mvn or mvn -c. If we were to embed > MWM into Maven, dropping phase invocation entirely could be a path forward > — but that's a much larger conversation than fixing this race condition. > > MWM and chained local repositories solve a different problem — > cross-project, cross-branch isolation of installed artifacts. That's > valuable, and it can coexist with project-local-repo. But it doesn't make > the race condition go away, because it still requires install, and Maven > still supports builds without it. > > So: do we fix the bug in the supported workflow, or do we deprecate the > workflow? We've just released rc6 — deprecating a supported workflow is a > Maven 5 conversation. The race condition fix is a 15-line change that can > land now. > > Guillaume > > Le mar. 4 août 2026 à 22:11, Tamás Cservenák <[email protected]> a > écrit : > > > Just to explain a bit more: > > Whenever I hear "I am doing this and this", I expect that it can be > > continued with something like "because of this and this". > > > > Basically, that the actor DOING the thing knows WHY he is doing the > thing. > > > > So, I am interested in the WHYs. > > > > For example: If I am working across multiple checkouts (projects), or > > I plan to limit the reactor later on (-rf etc), I want to make > > involved project(s) output build artifacts resolvable. > > This is my WHY for doing mvn install. > > > > Thanks > > T > > > > On Tue, 4 Aug 2026 at 21:59, Tamás Cservenák <[email protected]> > wrote: > > > > > > Jo, > > > > > > I get that, but this part: "many developers run mvn package or mvn > > verify". > > > I thought everyone runs "mvn clean install" :D Joke aside, why are > > > they doing that? > > > I mean, does running `mvn install` (instead of mvn verify) incur some > > > huge overhead? > > > Or are they being told to do so? So what is the explanation to run > > > (n-1)th and not n-th phase? > > > > > > > > > T > > > > > > On Tue, 4 Aug 2026 at 21:48, Guillaume Nodet <[email protected]> > wrote: > > > > > > > > THi all, > > > > > > > > > > > > Following the discussion on whether chained local repositories (à la > > MWM) > > > > could replace project-local-repo, I wanted to clarify the use cases > > each > > > > solves. They're complementary, not interchangeable. > > > > > > > > > > > > *What project-local-repo solves* > > > > > > > > project-local-repo was introduced in MNG-7629 to support > intra-reactor > > > > partial and resumable builds without requiring mvn install. It is > > populated > > > > on ProjectSucceeded regardless of the lifecycle goal — mvn package, > mvn > > > > verify, anything that produces artifacts. > > > > > > > > > > > > This enables workflows like: > > > > - mvn package then mvn test -pl :child — child finds sibling > artifacts > > > > - mvn verify fails at module-C, then mvn verify -rf :module-C — > > modules A > > > > and B's artifacts (including classifiers like sources.jar, test-jar, > > > > consumer POMs) are available from the previous run > > > > - mvn package -DskipTests then mvn surefire:test -pl :single-module — > > > > resolves dependencies from siblings > > > > > > > > The key detail is that classified/attached artifacts (sources.jar, > > > > test-jar, javadoc.jar, consumer POMs) are only resolvable from > > > > project-local-repo during resume. The target/classes fallback in > > > > ReactorReader only handles plain jars without classifiers. > > > > > > > > What chained local repositories solve > > > > > > > > Chained repos (via maven.repo.local.head / MWM) solve cross-project > > > > SNAPSHOT resolution with branch isolation. They allow different > > branches to > > > > have isolated install targets, so working on multiple branches (or > > multiple > > > > related projects) doesn't cause artifact conflicts in > ~/.m2/repository. > > > > > > > > This enables workflows like: > > > > - Build maven-resolver SNAPSHOT on branch feature-x, then build maven > > > > against it — without polluting ~/.m2/repository or conflicting with > the > > > > main branch > > > > - Multiple git worktrees of the same project, each with its own > install > > > > target > > > > > > > > Why one can't replace the other > > > > > > > > Chained repos require mvn install to populate the head repository. > They > > > > cannot serve the project-local-repo use case because many developers > > run > > > > mvn package or mvn verify without install. After mvn package, > > classified > > > > artifacts are in project-local-repo (populated on ProjectSucceeded) > > but not > > > > in any local repository. > > > > > > > > Conversely, project-local-repo is scoped to a single reactor — it > > cannot > > > > resolve artifacts across project boundaries. Chained repos solve this > > > > naturally. > > > > > > > > Regarding #12646 > > > > > > > > The race condition exists because project-local-repo currently lives > > inside > > > > target/, where maven-clean-plugin deletes it during parallel builds. > > The > > > > proposed fix (PR #12650) moves it to .mvn/target/project-local-repo — > > > > outside the reach of maven-clean-plugin, while keeping the semantic > > split > > > > (.mvn/ = config, .mvn/target/ = build output, gitignored). > > > > > > > > This is a minimal, targeted fix. Both mechanisms can coexist — > chained > > > > repos for cross-project branch isolation, project-local-repo for > > > > intra-reactor partial builds without install. > > > > > > > > PR: https://github.com/apache/maven/pull/12650 > > > > Issue: https://github.com/apache/maven/issues/12646 > > > > > > > > > > > > > > > > Le mar. 4 août 2026 à 21:26, Maarten Mulders <[email protected]> > a > > > > écrit : > > > > > > > > > Hi, > > > > > > > > > > The statement that "the unsolicited install happens [...] to make > the > > > > > resume `-r` feature work" is only partially true. The original > > solution > > > > > to get `mvn -r` to work did /not/ involve installing all artifacts > > in a > > > > > project-local repo. It was later refactored/rewritten by /other/ > > people > > > > > to work the way you describe. > > > > > > > > > > Thanks, > > > > > > > > > > Maarten > > > > > > > > > > On August 4, 2026 at 15:07, Tamás Cservenák wrote: > > > > > > Howdy, > > > > > > > > > > > > I would just reflect on a funny fact (for me at least): > > > > > > > > > > > > This whole problem (being solved on this thread), stems from one > > > > > > single thing: the unsolicited install that Maven 4 does (cf this > to > > > > > > user invoking `mvn install` explicitly). > > > > > > > > > > > > Moreover, this unsolicited install happens, for one thing, to > make > > the > > > > > > resume `-r` feature work. > > > > > > > > > > > > And the true irony is, that this resume feature is backed and > > > > > > advertised by folks, whose mantra is "do not `mvn install` but > `mvn > > > > > > verify`" (as install "pollutes' your local repository", whatever > > that > > > > > > means). > > > > > > > > > > > > That mantra can be now extended with "... as Maven 4 will install > > it, > > > > > > even if you did not ask for it" :) > > > > > > > > > > > > The more I think about it, the more I find this funny. > > > > > > > > > > > > Thanks > > > > > > T > > > > > > > > > > > > On Tue, 4 Aug 2026 at 14:56, Guillaume Nodet<[email protected]> > > wrote: > > > > > >> I like the .mvn/target/project-local-repo which solves the > > problem, > > > > > >> and also provides a good location where plugins could move some > > > > > >> temporary data files without being disturbed by the clean > > plugin. I'm > > > > > >> thinking about the flatten plugin, the release plugin, and > > probably > > > > > >> more. > > > > > >> > > > > > >> Le lun. 3 août 2026 à 16:47, Slawomir Jaranowski > > > > > >> <[email protected]> a écrit : > > > > > >>> Hi, > > > > > >>> > > > > > >>> On Mon, 3 Aug 2026 at 14:09, Guillaume Nodet< > > [email protected]> > > > > > wrote: > > > > > >>>> Hi all, > > > > > >>>> > > > > > >>>> I'd like to get your input on the fix for GH-12646 — a race > > condition > > > > > with > > > > > >>>> project-local-repo during parallel clean install builds. > > > > > >>>> > > > > > >>>> The problem > > > > > >>>> > > > > > >>>> When the root pom.xml has a parent that is also part of the > > reactor > > > > > (e.g. a > > > > > >>>> super-pom), MultiThreadedBuilder schedules the parent first, > > then > > > > > runs the > > > > > >>>> root project and child modules concurrently. Since clean and > > install > > > > > are > > > > > >>>> placed into the same TaskSegment, there is no barrier between > > them — > > > > > the > > > > > >>>> root project's maven-clean-plugin can delete target/ while > > sibling > > > > > modules > > > > > >>>> are concurrently writing artifacts into > > target/project-local-repo, > > > > > causing > > > > > >>>> the build to fail. > > > > > >>>> > > > > > >>>> Approaches considered > > > > > >>>> > > > > > >>>> 1. Lock-based synchronization (ReentrantReadWriteLock in > > > > > ReactorReader) > > > > > >>>> > > > > > >>>> Acquire a write lock when the project owning target/ enters > its > > clean > > > > > >>>> phase, and a read lock when installing artifacts. This > prevents > > the > > > > > crash > > > > > >>>> (concurrent access) but does not guarantee ordering — a module > > could > > > > > >>>> install artifacts before the root's clean starts, only to have > > them > > > > > wiped. > > > > > >>>> It also adds complexity to ReactorReader for what is > > fundamentally an > > > > > >>>> architectural problem. > > > > > >>>> > > > > > >>>> 2. Move project-local-repo to ~/.m2/ (user home) > > > > > >>>> > > > > > >>>> E.g. ~/.m2/local-repository/${projectName}_${hash}, similar to > > how > > > > > IntelliJ > > > > > >>>> stores project caches. This avoids both the race and the git > > concern, > > > > > but: > > > > > >>>> - Hard links (already used by ReactorReader) cannot cross > > filesystem > > > > > >>>> boundaries — if ~/.m2/ is on a different volume, every > artifact > > > > > becomes a > > > > > >>>> full copy > > > > > >>>> - Stale directories accumulate when projects are > deleted/moved, > > with > > > > > no > > > > > >>>> cleanup mechanism > > > > > >>>> - CI containers often share ~/.m2/ across builds, causing > > unwanted > > > > > >>>> accumulation > > > > > >>>> - Loses project locality (harder to inspect/debug) > > > > > >>>> > > > > > >>>> 3. Move project-local-repo to .mvn/project-local-repo (chosen) > > > > > >>>> > > > > > >>>> Move the directory from target/project-local-repo to > > > > > >>>> .mvn/project-local-repo. Since maven-clean-plugin only deletes > > > > > target/, the > > > > > >>>> race becomes structurally impossible. ReactorReader fully owns > > the > > > > > >>>> lifecycle — per-GAV cleanup when a project enters its clean > > phase, > > > > > install > > > > > >>>> on project success. The existing hard-link optimization > > continues to > > > > > work > > > > > >>>> since both directories are on the same filesystem. > > > > > >>>> > > > > > >>>> The trade-off is that .mvn/project-local-repo needs to be > > gitignored. > > > > > This > > > > > >>>> follows the Gradle convention where .gradle/ at the project > > root is > > > > > >>>> universally in .gitignore templates. Maven could also document > > this > > > > > >>>> convention or consider auto-appending the entry. > > > > > >>>> > > > > > >>>> The fix itself is minimal — the core change is a single line > in > > > > > >>>> getProjectLocalRepo(), and the rest is removing the lock > > > > > infrastructure > > > > > >>>> (net -40 lines). > > > > > >>>> > > > > > >>>> 4. Keep in target/ but use maven-clean-plugin fast mode > > > > > >>>> > > > > > >>>> The fast clean option (maven.clean.fast=true, since plugin > 3.2) > > > > > atomically > > > > > >>>> renames target/ instead of recursively deleting it. This would > > likely > > > > > avoid > > > > > >>>> the race, but it's opt-in and not the default — users hitting > > the bug > > > > > would > > > > > >>>> need to know about it. > > > > > >>>> > > > > > >>>> FWIW, a PR has been raised on m-clean-p master branch (4.x) to > > > > > refactor the > > > > > >>>> fast cleaner (fixing problems) and make it the default. > > > > > >>>> > > > > > >>>> Open questions > > > > > >>>> > > > > > >>>> - Is .mvn/ the right location, or should we consider a > different > > > > > >>>> project-root directory? > > > > > >>> maybe .mvn/target/project-local-repo > > > > > >>> it should be ignored by git > > > > > >>> > > > > > >>>> - Should Maven auto-add .mvn/project-local-repo to .gitignore, > > or > > > > > document > > > > > >>>> it as a convention? > > > > > >>>> - Are there other considerations I'm missing? > > > > > >>>> > > > > > >>>> PR:https://github.com/apache/maven/pull/12650 > > > > > >>>> Issue:https://github.com/apache/maven/issues/12646 > > > > > >>>> > > > > > >>>> Looking forward to your thoughts. > > > > > >>>> > > > > > >>>> Cheers > > > > > >>>> Guillaume Nodet > > > > > >>> > > > > > >>> > > > > > >>> -- > > > > > >>> Sławomir Jaranowski > > > > > >>> > > > > > >>> > > --------------------------------------------------------------------- > > > > > >>> To unsubscribe, e-mail:[email protected] > > > > > >>> For additional commands, e-mail:[email protected] > > > > > >>> > > > > > >> > > > > > >> -- > > > > > >> ------------------------ > > > > > >> Guillaume Nodet > > > > > >> > > > > > >> > > --------------------------------------------------------------------- > > > > > >> To unsubscribe, e-mail:[email protected] > > > > > >> For additional commands, e-mail:[email protected] > > > > > >> > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail:[email protected] > > > > > > For additional commands, e-mail:[email protected] > > > > > > > > > > > > > > > > > > > > > > -- > > > > ------------------------ > > > > Guillaume Nodet > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > -- > ------------------------ > Guillaume Nodet >
