Re: [DISCUSS] Fix for #12646 — moving project-loca l-repo out of target/

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]
> >
> >
>