Re: [DISCUSS] Fix for #12646 — moving pro ject-local-repo out of target/

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