Oh, one more thing: MWM combined with build cache extension and Mimir should rock! BC needs a bit more love, but is doable.
Thanks T On Tue, Aug 4, 2026, 20:28 Romain Manni-Bucau <[email protected]> wrote: > Maybe get back to split repo which does adresses it since years - recale we > were solving that before split repo using fake groupid containing the > branches? ;) > > Splitting our effort and duplicating concurrent solutions doesn't sound > very future friendly to me. > > There are good in all, just need to converge to a single solution in > org.apache.maven écosystème IMHO. > > > 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, 20:20, Tamás Cservenák <[email protected]> a écrit > : > > > The "be able to work on two different branch of same project" is being > > addressed by MWM: > > https://github.com/maveniverse/mwm/blob/main/README.md > > > > The current state is just showcasing the idea, but future plans are to > > expose (via Mojos) controls like: > > * associate projects with workspace > > * listing/maintenance/purge of workspaces (or just user performs usual > > local repository hygiene; as is using Mimir) -- and nukes it all > > * etc > > > > Thanks > > T > > > > On Tue, 4 Aug 2026 at 20:03, Guillaume Nodet <[email protected]> wrote: > > > > > > Not being able to work on two different branch of the same project > seems > > a > > > real problem to me. > > > And the resume seems like a well adopted feature. > > > I'd rather hear solutions than just dismissing those two use cases. > > > > > > If we can leverage the chained repo easily, that would be great. > > However, > > > this means you can't easily share things anymore between two projects. > If > > > `mvn install` goes to a custom repository, you cannot easily build a > > > project and another one depending on it, unless you change the config > > > somehow IIUC. > > > > > > I’m not sure it’s reallly wise to try to change the semantics or the > > usage > > > of the install and deploy goal either. > > > > > > Le mar. 4 août 2026 à 15:08, Tamás Cservenák <[email protected]> a > > écrit : > > > > > > > > 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] > > > > >
