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

--00000000000043efa7065825fc91
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

well i'd like to avoid to have 2 "target" and putting target in .mvn
doesn't solve the watch issue (it is unrelated to .git strictly speaking
even if there are cases it will not be ignored cause not everybody uses
"target" in .gitignore even if common).
since .m2 already has a ton of living and even temp files (snapshots for ex
which are still needed there quite often) then it doesn't hurt as much as
it can sound to do it there, in particular with split repo it will be free
and "by design"

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-97817884=
73064>
Javaccino <https://javaccino.dev/> founder (Java/.NET service - contact via
linkedin)


Le lun. 3 ao=C3=BBt 2026 =C3=A0 17:05, Matthias B=C3=BCnger <mbuenger@apach=
e.org> a =C3=A9crit :

> Hi,
>
> I strongly think, we should keep in somewhere in the project folder (so
> no m2 etc.) to keep it visible and show that it's temp. Similar to
> Slawek: Having a "/target" will keep it out of git, with common
> gitignores, so what about something like "project-local-repo/target" -
> so it's clear on high level what the folder is (and not hided in
> optional configuration .mvn folder) and due /target it's not added to git=
.
>
> Matthias
>
> Am 03.08.2026 um 14:09 schrieb Guillaume Nodet:
> > Hi all,
> >
> > I'd like to get your input on the fix for GH-12646 =E2=80=94 a race con=
dition
> 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 ar=
e
> > placed into the same TaskSegment, there is no barrier between them =E2=
=80=94 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 cra=
sh
> > (concurrent access) but does not guarantee ordering =E2=80=94 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 =E2=80=94 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 =E2=80=94 per-GAV cleanup when a project enters its clean pha=
se,
> install
> > on project success. The existing hard-link optimization continues to wo=
rk
> > 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 =E2=80=94 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=3Dtrue, 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 =E2=80=94 users hitting t=
he 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?
> > - 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
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

--00000000000043efa7065825fc91--