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