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

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