Le ven. 7 août 2026 à 19:00, Romain Manni-Bucau
<[email protected]> a écrit :
>
> Le mer. 5 août 2026 à 23:57, Guillaume Nodet <[email protected]> a écrit :
>
> > Le mer. 5 août 2026 à 21:54, Romain Manni-Bucau <[email protected]> a
> > écrit :
> >
> > > If we are going to break project.build.outputDirectory (.mvn/target)
> > then
> > > we should step back and break it keeping it sane so make it hierarchical
> > > instead of flat (target/repo, target/build/foo.jar etc).
> > >
> >
> > I think the idea was to use ${session.root}/.mvn/target/project-local-repo,
> > which is in line with your suggestion.
> >
>
> only if you drop session.root/target to move it to .mvn/target (and get
> back the same issue), the proposal is a single project.build.directory then
> a hierarchy there
Which same issue ? The problem is a race condition when cleaning target.
The .mvn/target is out of control of the clean plugin.
I'm fine with moving it to ~/whatever, but there's a real drawback if
it does not
belong to the same file system, as hard links would not work, so it would incur
the cost of a real copy. And we'd need a key to differentiate the projects, so
maybe the hash of the project root folder path ?
>
>
> >
> > That said what we say if we want to leak and violate cleanable with clean
> > > plugin rulé then it should belong to .m2 until we restructure build dir
> > to
> > > avoir a mess and a ton of New config for that purpose
> > > (project.build.leakingDirectory?).
> > >
> >
> > Yes good idea, i've just added a maven.project.local.repo property with a
> > default value of
> > ${maven.rootDirectory}/.mvn/target/project-local-repo specified in the
> > ${MAVEN_HOME}/conf/maven-user.properties, (documents, but commented by
> > default),
> > so that anyone can change it.
> >
>
> maven.project.local.repo overlaps too much with maven.local.repo IMHO and
> as mentionned I think we do it wrong if we put temporary files in a ton of
> folders
A few other suggestions:
* maven.reactor.outputRepository
* maven.reactor.localRepo
* maven.build.outputRepository
* maven.project.outputRepository
* maven.reactor.repo
>
>
> >
> >
> > > Side question: nobody jumps on split repo solution so I assume we'll drop
> > > the feature anytime soon in a coming release? 🤔
> > >
> >
> > Chained repo != split repo.
> > Split repo (available from 3.9.x) has a main drawback imho., as this
> > affects the global ~/.m2/repository,
> > so all your maven projects need to be configured exactly the same way to
> > use the same local repositories.
> >
>
> which is awesome for worktrees/branches work
>
>
> > For chained repo, I think this could definitely be leveraged to provide
> > workspace isolation, it seems
> > a really nice feature to add for 4.1, if there's anything to do in maven
> > for it.
> >
>
> the only missing feature IMHO is clean plugin being able to clean that
> folder but since the goal is to share to module outside the reactor already
> built artifacts it belongs outside the project to me in a temporary repo so
> this is the feature we should build upon and not a new local one which
> competes with 2 existing feature no?
They can be lazily created based on branch names, but a few commands to
list / delete those would be good imho. Or to create one, I'm not sure we want
to change by default the install command to not install in the local repo.
I really don't think the two really compete. One serves to fix the
`mvn package`
command. That's why it has been implemented. The other proposal serves to
share and isolate branch work on a single or multiple projects. The chained
repos won't fix `mvn package` at all.
>
>
> >
> > Guillaume
> >
> >
> > > 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 mer. 5 août 2026, 21:47, Tamás Cservenák <[email protected]> a
> > écrit
> > > :
> > >
> > > > Right, will shut up now, just allow me one more question:
> > > > what happens when a multi-project build builds AND uses a plugin from
> > > > the reactor?
> > > >
> > > > T
> > > >
> > > > On Tue, 4 Aug 2026 at 23:36, Guillaume Nodet <[email protected]>
> > wrote:
> > > > >
> > > > > I think we're talking past each other. The race condition in #12646
> > is
> > > > not
> > > > > about reactor limiting or partial builds. It happens in a plain full
> > > mvn
> > > > > clean install -T N — no -pl, no -f, no -r. The root module's clean
> > > phase
> > > > > deletes target/ while sibling modules concurrently write to
> > > > > target/project-local-repo. That's the bug, and it needs fixing
> > > regardless
> > > > > of how we feel about partial builds.
> > > > >
> > > > > Now, on reactor limiting — you're actually making the case for
> > > > > project-local-repo. You say mvn -f impl/maven-core shouldn't be
> > > expected
> > > > to
> > > > > work because omitted modules need to be resolvable. That's exactly
> > what
> > > > > project-local-repo makes possible: after a full mvn verify, the
> > > artifacts
> > > > > are there for a subsequent partial build, without requiring install.
> > > > That's
> > > > > the feature MNG-7629 added. Whether we think that's a good feature
> > is a
> > > > > separate discussion — but it's shipped, it's in 4.0.0-rc6.
> > > > >
> > > > > The PR fixes a race condition in existing, released code. Can we
> > focus
> > > on
> > > > > whether the fix is correct? Start a separate discussion to discuss
> > > other
> > > > > problems.
> > > > >
> > > > >
> > > > > Le mar. 4 août 2026 à 23:25, Tamás Cservenák <[email protected]> a
> > > > écrit :
> > > > >
> > > > > > "mvn verify and mvn package are supported lifecycle invocations in
> > > > > > Maven" -- yes, they are, nobody claimed the opposite.
> > > > > > "They work for single-module projects." -- as they per-def can have
> > > no
> > > > > > other dependencies than "external" ones (coming from remote
> > > > > > repository; those are "done-done" already)
> > > > > > "They're supposed to work for multi-module projects too" -- yes,
> > and
> > > > > > they do: I can just fine mvn verify on Maven master, it will work.
> > > > > > But, I should not expect later on, that `mvn -f impl/maven-core`
> > will
> > > > > > work.
> > > > > >
> > > > > > To me this looks like "reactor limiting" does it wrong. Maven,
> > right
> > > > > > now, "pretend that the omitted module does not exist" (hence, it
> > > needs
> > > > > > to be resolvable), while the JAR, and whatever it produces, may be
> > > > > > present in target from previous invocation...
> > > > > >
> > > > > > T
> > > > > >
> > > > > > On Tue, 4 Aug 2026 at 22:57, Guillaume Nodet <[email protected]>
> > > > wrote:
> > > > > > >
> > > > > > > I don't think "isolation" is the right framing here. The question
> > > is
> > > > > > > simpler than that.
> > > > > > >
> > > > > > > mvn verify and mvn package are supported lifecycle invocations in
> > > > Maven.
> > > > > > > They work for single-module projects. They're supposed to work
> > for
> > > > > > > multi-module projects too — and they do, thanks to
> > > > project-local-repo and
> > > > > > > the ReactorReader. That mechanism was added (MNG-7629) precisely
> > to
> > > > make
> > > > > > > the reactor resolve cross-module artifacts during builds that
> > don't
> > > > run
> > > > > > > install.
> > > > > > >
> > > > > > > So we have a supported feature that has a race condition. The fix
> > > is
> > > > > > > straightforward: move the directory out of the blast radius of
> > > clean.
> > > > > > > That's what PR #12650 does.
> > > > > > >
> > > > > > > The alternative is to say: "actually, mvn package and mvn verify
> > > are
> > > > not
> > > > > > > supported for multi-module builds — you must always run mvn
> > > install."
> > > > > > > That's a valid position, but it's a breaking change in semantics
> > > that
> > > > > > needs
> > > > > > > a proper discussion, a deprecation path, and clear documentation.
> > > We
> > > > > > can't
> > > > > > > just leave the race condition unfixed and tell users to install
> > an
> > > > > > > extension.
> > > > > > >
> > > > > > > If we want install to be the only goal people should use, we
> > should
> > > > make
> > > > > > > that explicit. We could drop the mvn compile reactor support too
> > > > (since
> > > > > > > it's broken for the same reasons), make clean an option rather
> > > than a
> > > > > > goal,
> > > > > > > and simplify the user experience to just mvn or mvn -c. If we
> > were
> > > to
> > > > > > embed
> > > > > > > MWM into Maven, dropping phase invocation entirely could be a
> > path
> > > > > > forward
> > > > > > > — but that's a much larger conversation than fixing this race
> > > > condition.
> > > > > > >
> > > > > > > MWM and chained local repositories solve a different problem —
> > > > > > > cross-project, cross-branch isolation of installed artifacts.
> > > That's
> > > > > > > valuable, and it can coexist with project-local-repo. But it
> > > doesn't
> > > > make
> > > > > > > the race condition go away, because it still requires install,
> > and
> > > > Maven
> > > > > > > still supports builds without it.
> > > > > > >
> > > > > > > So: do we fix the bug in the supported workflow, or do we
> > deprecate
> > > > the
> > > > > > > workflow? We've just released rc6 — deprecating a supported
> > > workflow
> > > > is a
> > > > > > > Maven 5 conversation. The race condition fix is a 15-line change
> > > > that can
> > > > > > > land now.
> > > > > > >
> > > > > > > Guillaume
> > > > > > >
> > > > > > > Le mar. 4 août 2026 à 22:11, Tamás Cservenák <
> > [email protected]>
> > > a
> > > > > > écrit :
> > > > > > >
> > > > > > > > Just to explain a bit more:
> > > > > > > > Whenever I hear "I am doing this and this", I expect that it
> > can
> > > be
> > > > > > > > continued with something like "because of this and this".
> > > > > > > >
> > > > > > > > Basically, that the actor DOING the thing knows WHY he is doing
> > > the
> > > > > > thing.
> > > > > > > >
> > > > > > > > So, I am interested in the WHYs.
> > > > > > > >
> > > > > > > > For example: If I am working across multiple checkouts
> > > (projects),
> > > > or
> > > > > > > > I plan to limit the reactor later on (-rf etc), I want to make
> > > > > > > > involved project(s) output build artifacts resolvable.
> > > > > > > > This is my WHY for doing mvn install.
> > > > > > > >
> > > > > > > > Thanks
> > > > > > > > T
> > > > > > > >
> > > > > > > > On Tue, 4 Aug 2026 at 21:59, Tamás Cservenák <
> > > [email protected]>
> > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Jo,
> > > > > > > > >
> > > > > > > > > I get that, but this part: "many developers run mvn package
> > or
> > > > mvn
> > > > > > > > verify".
> > > > > > > > > I thought everyone runs "mvn clean install" :D Joke aside,
> > why
> > > > are
> > > > > > > > > they doing that?
> > > > > > > > > I mean, does running `mvn install` (instead of mvn verify)
> > > incur
> > > > some
> > > > > > > > > huge overhead?
> > > > > > > > > Or are they being told to do so? So what is the explanation
> > to
> > > > run
> > > > > > > > > (n-1)th and not n-th phase?
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > T
> > > > > > > > >
> > > > > > > > > On Tue, 4 Aug 2026 at 21:48, Guillaume Nodet <
> > > [email protected]>
> > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > THi all,
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Following the discussion on whether chained local
> > > repositories
> > > > (à
> > > > > > la
> > > > > > > > MWM)
> > > > > > > > > > could replace project-local-repo, I wanted to clarify the
> > use
> > > > cases
> > > > > > > > each
> > > > > > > > > > solves. They're complementary, not interchangeable.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > *What project-local-repo solves*
> > > > > > > > > >
> > > > > > > > > > project-local-repo was introduced in MNG-7629 to support
> > > > > > intra-reactor
> > > > > > > > > > partial and resumable builds without requiring mvn install.
> > > It
> > > > is
> > > > > > > > populated
> > > > > > > > > > on ProjectSucceeded regardless of the lifecycle goal — mvn
> > > > > > package, mvn
> > > > > > > > > > verify, anything that produces artifacts.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > This enables workflows like:
> > > > > > > > > > - mvn package then mvn test -pl :child — child finds
> > sibling
> > > > > > artifacts
> > > > > > > > > > - mvn verify fails at module-C, then mvn verify -rf
> > > :module-C —
> > > > > > > > modules A
> > > > > > > > > > and B's artifacts (including classifiers like sources.jar,
> > > > > > test-jar,
> > > > > > > > > > consumer POMs) are available from the previous run
> > > > > > > > > > - mvn package -DskipTests then mvn surefire:test -pl
> > > > > > :single-module —
> > > > > > > > > > resolves dependencies from siblings
> > > > > > > > > >
> > > > > > > > > > The key detail is that classified/attached artifacts
> > > > (sources.jar,
> > > > > > > > > > test-jar, javadoc.jar, consumer POMs) are only resolvable
> > > from
> > > > > > > > > > project-local-repo during resume. The target/classes
> > fallback
> > > > in
> > > > > > > > > > ReactorReader only handles plain jars without classifiers.
> > > > > > > > > >
> > > > > > > > > > What chained local repositories solve
> > > > > > > > > >
> > > > > > > > > > Chained repos (via maven.repo.local.head / MWM) solve
> > > > cross-project
> > > > > > > > > > SNAPSHOT resolution with branch isolation. They allow
> > > different
> > > > > > > > branches to
> > > > > > > > > > have isolated install targets, so working on multiple
> > > branches
> > > > (or
> > > > > > > > multiple
> > > > > > > > > > related projects) doesn't cause artifact conflicts in
> > > > > > ~/.m2/repository.
> > > > > > > > > >
> > > > > > > > > > This enables workflows like:
> > > > > > > > > > - Build maven-resolver SNAPSHOT on branch feature-x, then
> > > build
> > > > > > maven
> > > > > > > > > > against it — without polluting ~/.m2/repository or
> > > conflicting
> > > > > > with the
> > > > > > > > > > main branch
> > > > > > > > > > - Multiple git worktrees of the same project, each with its
> > > own
> > > > > > install
> > > > > > > > > > target
> > > > > > > > > >
> > > > > > > > > > Why one can't replace the other
> > > > > > > > > >
> > > > > > > > > > Chained repos require mvn install to populate the head
> > > > repository.
> > > > > > They
> > > > > > > > > > cannot serve the project-local-repo use case because many
> > > > > > developers
> > > > > > > > run
> > > > > > > > > > mvn package or mvn verify without install. After mvn
> > package,
> > > > > > > > classified
> > > > > > > > > > artifacts are in project-local-repo (populated on
> > > > ProjectSucceeded)
> > > > > > > > but not
> > > > > > > > > > in any local repository.
> > > > > > > > > >
> > > > > > > > > > Conversely, project-local-repo is scoped to a single
> > reactor
> > > —
> > > > it
> > > > > > > > cannot
> > > > > > > > > > resolve artifacts across project boundaries. Chained repos
> > > > solve
> > > > > > this
> > > > > > > > > > naturally.
> > > > > > > > > >
> > > > > > > > > > Regarding #12646
> > > > > > > > > >
> > > > > > > > > > The race condition exists because project-local-repo
> > > currently
> > > > > > lives
> > > > > > > > inside
> > > > > > > > > > target/, where maven-clean-plugin deletes it during
> > parallel
> > > > > > builds.
> > > > > > > > The
> > > > > > > > > > proposed fix (PR #12650) moves it to
> > > > > > .mvn/target/project-local-repo —
> > > > > > > > > > outside the reach of maven-clean-plugin, while keeping the
> > > > semantic
> > > > > > > > split
> > > > > > > > > > (.mvn/ = config, .mvn/target/ = build output, gitignored).
> > > > > > > > > >
> > > > > > > > > > This is a minimal, targeted fix. Both mechanisms can
> > coexist
> > > —
> > > > > > chained
> > > > > > > > > > repos for cross-project branch isolation,
> > project-local-repo
> > > > for
> > > > > > > > > > intra-reactor partial builds without install.
> > > > > > > > > >
> > > > > > > > > > PR: https://github.com/apache/maven/pull/12650
> > > > > > > > > > Issue: https://github.com/apache/maven/issues/12646
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Le mar. 4 août 2026 à 21:26, Maarten Mulders <
> > > > > > [email protected]> a
> > > > > > > > > > écrit :
> > > > > > > > > >
> > > > > > > > > > > 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]
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > ------------------------
> > > > > > > > > > Guillaume Nodet
> > > > > > > >
> > > > > > > >
> > > > ---------------------------------------------------------------------
> > > > > > > > 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]
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > ------------------------
> > > > > Guillaume Nodet
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [email protected]
> > > > For additional commands, e-mail: [email protected]
> > > >
> > > >
> > >
> >
> >
> > --
> > ------------------------
> > Guillaume Nodet
> >
--
------------------------
Guillaume Nodet
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
