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

Sergey Chernov <[email protected]> Mon, 3 Aug 2026 18:07:34 +0200
Newsgroups gmane.comp.jakarta.turbine.maven.devel
Message-ID <CAJ-bKnnLgCd06kO0watDnpYe=fVcLOXvY4y=UqeFYTK3by9Bcg@mail.gmail.com>
--00000000000023a38a065826bd50
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Let me duplicate my message from GH here. Originally, the issue with
target/ happens because of the race condition during the clean phase (see
https://github.com/apache/maven/issues/12646 description)

This is a bit radical, but now it could a good moment at least to highlight
this idea, I was thinking for a long time already:

Maven historically executes commands like mvn clean install as a single
sequence of goals (yes, these are two lifecycles, but these are aggregated
to a single list of goals passed for simple iteration into
DefaultMojosExecutionStrategy).
Other build tools, like Gradle, do it a different way: for each "lifecycle"
(I know it's different on the low level in Gradle, there are tasks) it
executes the requestested goals/lifecycles for all modules, then goes to
the next requested lifecycle.
So, the mvn clean install in this case would look like this:

   - run clean lifecycle for all modules [optionally in parallel, but still
   only clean]
   - when the clean lifecycle is over, run default lifecycle [validate..
   install] for all modules

IMO this behavior has advantages, but not sure it's compatible with e.g. -r=
f
 (--resume-from), or all kinds of CLI-executed maven goals (mvn plugin:goal
).
Is this a considerable option? I know this may be too late for such a
drastic change, but this could be a possible solution as it eliminates the
race condition with cleaning target/ of the root module.
Am I missing something?

On Mon, Aug 3, 2026 at 5:58=E2=80=AFPM Guillaume Nodet <[email protected]> =
wrote:

> One thing I forgot to mention is that when an artifact is copied from a
> target dir to the project local repo, we try to use a hard link instead o=
f
> a real copy. If we move it to ~/.m2, there are chances that they do not
> belong to the same mount and thus fallback to a real copy instead of a
> link.
>
> Le lun. 3 ao=C3=BBt 2026 =C3=A0 17:22, Matthias B=C3=BCnger <mbuenger@apa=
che.org> a
> =C3=A9crit :
>
> > > 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 muc=
h
> as
> > > it can sound to do it there, in particular with split repo it will be
> > free
> > > and "by design"
> >
> > Are you sure that the Maven process always has deletion rights in .m2,
> > esp in container environments where .m2 is just injected from outsite t=
o
> > avoid downloading stuff over (and over and therefore also shared across
> > multiple). So like having "r-x" on directory, but files have "rw-"?
> >
> >
> >
>
> --
> ------------------------
> Guillaume Nodet
>

--00000000000023a38a065826bd50--