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