Thanks for taking a look at this! Comments inline below: On Wed, 30 Jul 2025 at 19:20, Hervé Boutemy <[email protected]> wrote:
> thanks for sharing this step: useful to study simple code > > > forcing user to do "mvn install myplugin:mygoal" instead of "mvn deploy" > is > cheating :) notice that it opens an idea: Sonatype plugin could be used that way, that > would be less tricky inside Maven, that could work with Maven 4 > > but I really hoped that we could do something in deploy:deploy that is > bound > to the deploy phase > > I agree but as an initial attempt, I wanted to isolate it. We can absolutely integrate it closer to make it happen when we do maven deploy. Should the current deploy still work as is and we add an extra flag to determine which "mode" we publish with or should we change the way deploy works to only use the new publish process? > > on uploading module (sub-project) per module, it's definitively a no go: > having > 10s or even 100s of modules happens a lot, we need to do a single bundle > = what the existing deployAtEnd option prepares quite well for > Yes, I am working on a mega bundle using exactly that logic. There is a size limit on the bundle of 1 GB so I think it would be useful to have the "deploy each module separately" as an option. > > > reading the code, I finally understood one key aspect: > we need to create a bundle, that one I knew > but what I got is that the bundle is not PUT like deploy usually does with > http: it is POSTed > > so in addition to adding an option to create a bundle instead of deploying > each file separately, we'll also need to add an option to not PUT file but > HTTP > POST, with url and all Maven Central-specific data being in POM > distributionManagement > Yes, it's not even the common "post with attachment" but post as multipart... We already have the url param in distribution management and the username/token is retrieved from the settings based on the id so that is all good. The question is if we want a parameter in distributionmanagement or in the plugin config to give the user an alternative to deploy as it works today or deploy using the new central api? Best regards, Per > > > I'm sure it is feasible, I just did not have time to dive in deploy:deploy > code sufficiently yet... > > Le lundi 28 juillet 2025, 21:52:55 CEST Per Nyfelt a écrit : > > Hi, > > > > I have a proof of concept working here: > > > https://github.com/perNyfelt/maven-deploy-plugin/tree/add_central_support > > (the code can be much better integrated with the existing plugin, this > > is just a PoC). > > > > I used it to successfully uploaded and validate this project to central: > > https://github.com/perNyfelt/maven-central-publishing-example > > > > using ` mvn -DautoDeploy=false clean install deploy:publish` > > > > (the autodeploy flag is set to false so it only does the upload and > > waits at central for an action i.e. to be dropped or published manually) > > > > There is also a bundle step that creates the zip and also does some > > validation (so you don't have to actually try to upload the bundle to > > central to get feedback) that can be invoked separately with ` mvn > > -DautoDeploy=false clean verify deploy:bundle` > > > > Anyway, the deploy:publish deploys 4 bundles to central: > > > > 1. The aggregator project containing the pom (+ asc, md5, sha-1 and > sha-256) > > > > 2. common containing jar, source, javadoc and pom (+ asc, md5, sha-1 and > > sha-256) > > > > 3. subA (that depends on common) containing jar, source, javadoc and pom > > (+ asc, md5, sha-1 and sha-256) > > > > 4. subB (that depends on common) containing jar, source, javadoc and pom > > (+ asc, md5, sha-1 and sha-256) > > > > I will see if i can add an support for the "deployAtEnd" flag to create > > a mega-bundle instead and upload that. > > > > One thing that i found a little tricky is that we don't deploy the > > effective pom but rather the original pom (at least that's the one that > > is signed so that's the only readily available choice) and the central > > validation rules requires the license, developer, description and scm > > sections to be present. In the effective pom these are inherited from > > the parent but the validation logic in central does not care about that > > and rejects the deploy unless they are explicitly present. Maybe the > > validation will work differently in the mega-bundle. I'll will > > investigate... > > > > Best regards, > > > > Per > > > > On 7/22/25 19:16, Hervé Boutemy wrote: > > > one first step we could try could be adding a "deployToBundle" > parameter > > > to the deploy plugin, that would trigger an "at end" behaviour that > would > > > build a zip with all the deferred files, instead of copying each file > > > separately > > > > > > then see how just sending the bundle to the target (file: or https: or > > > scp: or ...) would do the job > > > > > > this could be a minimalistic approach, that would have the benefit of > > > showing "bundle vs individual deploy" approaches > > > > > > > > > njord is that approach on steroids = really manage a local staging area > > > (or name it as you want) and decide in a separate plugin where to put > the > > > staging area content and in which detailed format (PUT individual > files, > > > send everything as a unique archive, split the archive in smaller ones, > > > or any future strategy)> > > > On 2025/07/22 12:14:28 Per Nyfelt wrote: > > >> It CAN be deployed as a single zip but it does not have to be. The > > >> downside > > >> of deploying each module separately is that if one deployment fails > then > > >> you end up with a "partial" deploy (from the point of view of the > whole > > >> project) but I think you only end up in this situation in the > beginning > > >> when you have not configured everything properly. If we do internal > > >> validation first (check that an asc, md5 and sha1 accompanies each > > >> artifact) then this kind of error can be eliminated. What remains > would > > >> then be network errors in which case you would just deploy the failed > > >> module again. > > >> > > >> Regards, > > >> Per > > >> > > >> On Tue, 22 Jul 2025 at 13:25, Guillaume Nodet <[email protected]> > wrote: > > >>> And I think that's exactly the problem as the deployment needs to be > a > > >>> single zip file IIUC. > > >>> > > >>> Guillaume > > >>> > > >>> Le mar. 22 juil. 2025 à 12:28, Per Nyfelt <[email protected]> a > > >>> écrit > > >>> > > >>>> Hi Tamas, > > >>>> > > >>>> I think it would work. Each part is zipped up and deployed e.g. > > >>>> assuming > > >>>> you have a multimodule project like this: > > >>>> Aggregator > > >>>> > > >>>> - common > > >>>> - subA (depends on common) > > >>>> - subB (depends on common) > > >>>> > > >>>> Deploying all of this would mean 4 zip files are created and > published > > >>>> 1. The aggregator is just the pom (+ asc, md5 and sha1) > > >>>> 2. common is the pom, jar, javadoc and sources (all signed and with > md5 > > >>> > > >>> and > > >>> > > >>>> sha1 files) > > >>>> 3. subA is the pom, jar, javadoc and sources (all signed and with > md5 > > >>>> and > > >>>> sha1 files) > > >>>> 4 subB is the pom, jar, javadoc and sources (all signed and with md5 > > >>>> and > > >>>> sha1 files) > > >>>> > > >>>> That should work fine i think or am i missing something? > > >>>> > > >>>> Regards, > > >>>> Per > > >>>> > > >>>> On Tue, 22 Jul 2025 at 11:13, Tamás Cservenák <[email protected]> > > >>> > > >>> wrote: > > >>>>> Per, > > >>>>> > > >>>>> You cannot publish to central using plugin bound to lifecycle as it > > >>> > > >>> will be > > >>> > > >>>>> invoked in every module/subproject... Portal needs "at end; all > > >>> > > >>> artifacts" > > >>> > > >>>>> kind of operation and Maveniverse Njord does that without > interference > > >>> > > >>> to > > >>> > > >>>>> your build. > > >>>>> > > >>>>> Maven4 has improved lifecycle with "after:all" but Maven3 does > not, it > > >>>>> needs a bit more. > > >>>>> > > >>>>> T > > >>>>> > > >>>>> On Tue, Jul 22, 2025, 11:07 Per Nyfelt <[email protected]> > wrote: > > >>>>>> Hi, > > >>>>>> How about adding a deployToCentral (or similar) goal to the > > >>>>>> maven-deploy-plugin that uses the new API so that this is > supported > > >>>>>> "natively"? > > >>>>>> I would be willing to implement it if you think it's a good idea. > > >>>>>> > > >>>>>> Regards > > >>>>>> Per > > >>>>>> > > >>>>>> On Tue, 22 Jul 2025 at 10:39, Jon Harper <[email protected]> > > >>> > > >>> wrote: > > >>>>>>> Hi Hervé, > > >>>>>>> thanks for looking into it. Did you try the sonatype > compatibility > > >>>>>>> service ? > > >>> > > >>> > https://central.sonatype.org/publish/publish-portal-ossrh-staging-api > > >>> > > >>>>>>> Also, while the governance and roadmap of > > >>>>>>> central-publishing-maven-plugin is not open, the code itself is > OSS > > >>>>>>> (uses the apache license v2 as indicated in the pom > > >>> > > >>> > https://repo1.maven.org/maven2/org/sonatype/central/central-publishing-m > > >>> aven-plugin/0.8.0/central-publishing-maven-plugin-0.8.0.pom>>> > > >>>>>>> ) > > >>>>>>> Cheers, > > >>>>>>> Jon > > >>>>>>> > > >>>>>>> On Sat, Jul 19, 2025 at 10:13 PM Hervé Boutemy < > > >>> > > >>> [email protected]> > > >>> > > >>>>>>> wrote: > > >>>>>>>> deep dive done, with personal evaluation > > >>>>>>>> > > >>>>>>>> https://github.com/apache/maven-studies/tree/deploy > > >>>>>>>> > > >>>>>>>> happy to discuss and complete the review > > >>>>>>>> > > >>>>>>>> Le jeudi 17 juillet 2025, 03:53:40 CEST Hervé Boutemy a écrit : > > >>>>>>>>> I finally stopped procrastinating and took time to test > > >>>>>>>>> > > >>>>>>>>> https://github.com/apache/maven-studies/tree/deploy > > >>>>>>>>> > > >>>>>>>>> This does not yet give me a strong answer about what I > > >>> > > >>> personally > > >>> > > >>>>>> would > > >>>>>> > > >>>>>>>>> choose to promote, but at least better understanding of the > > >>> > > >>> misc > > >>> > > >>>>>>> options > > >>>>>>> > > >>>>>>>>> Le mardi 8 juillet 2025, 08:45:25 CEST Hervé Boutemy a écrit : > > >>>>>>>>>> it seems we're back to Maven history of: > > >>>>>>>>>> 1. publication to simple file systems (eventually shared) > > >>>>>>>>>> 2. multi-module (aka. multi-subproject) publication > > >>>>>>>>>> 3. multi-file publication in a single gav > > >>>>>>>>>> > > >>>>>>>>>> On the positive side, this has been very flexible and > > >>> > > >>> perfect for > > >>> > > >>>>>>>>>> downloads. But on the negative side, this leads to quite > > >>>>> > > >>>>> undefined > > >>>>> > > >>>>>>>>>> publication protocol, and misunderstood, even when we tried > > >>> > > >>> to > > >>> > > >>>>>> share > > >>>>>> > > >>>>>>> some > > >>>>>>> > > >>>>>>>>>> doc > > >>>>>>>>>> > > >>>>>>>>>> https://maven.apache.org/repository/layout.html > > >>>>>>>>>> > > >>>>>>>>>> In the past, the complaint was that there was no "standard" > > >>> > > >>> REST > > >>> > > >>>>>> API > > >>>>>> > > >>>>>>> to > > >>>>>>> > > >>>>>>>>>> publish (ignoring that REST did not exist when Maven was > > >>>>> > > >>>>> growing). > > >>>>> > > >>>>>>>>>> Now there is a REST API with proper documentation > > >>>>>>>>>> > > >>>>>>>>>> https://central.sonatype.com/api-doc > > >>>>>>>>>> > > >>>>>>>>>> We could expect everybody to be happy, but no. > > >>>>>>>>>> We are discovering it is perfect for smaller publications. > > >>>>>>>>>> But it opens questions for bigger publications. > > >>>>>>>>>> > > >>>>>>>>>> And yes, we're still in a half undocumented mix of approaches > > >>>>>>>>>> (Maven-native > > >>>>>>>>>> per-file PUT vs REST API for publishing an archive vs how to > > >>>>> > > >>>>> split > > >>>>> > > >>>>>>> multi- > > >>>>>>> > > >>>>>>>>>> module?) > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> Reading Njörðr description > > >>>>>>> > > >>>>>>> https://maveniverse.eu/docs/njord/what-is-it/, > > >>>>>>> > > >>>>>>>>>> it is a Maven Resolver Repository Connector, looks like a > > >>> > > >>> good > > >>> > > >>>>>>> integration > > >>>>>>> > > >>>>>>>>>> in the native Maven CLI: please call it something like > > >>> > > >>> "Njörðr > > >>> > > >>>>>>> publisher" > > >>>>>>> > > >>>>>>>>>> and I may remember what it does... > > >>>>>>>>>> > > >>>>>>>>>> I definitively need to dive into it: very interesting. > > >>>>>>>>>> And next spte will be to have a wider community understand > > >>> > > >>> all > > >>> > > >>>>>> these > > >>>>>> > > >>>>>>>>>> concepts, as beginning of all the issues is that we're > > >>> > > >>> touching > > >>> > > >>>>>> many > > >>>>>> > > >>>>>>>>>> in-depth aspects that are unknown to many. > > >>>>>>>>>> > > >>>>>>>>>> One additional TODO on my ever growing TODO list... > > >>>>>>>>>> > > >>>>>>>>>> Regards, > > >>>>>>>>>> > > >>>>>>>>>> Hervé > > >>>>>>>>>> > > >>>>>>>>>> Le lundi 7 juillet 2025, 16:48:39 CEST Tamás Cservenák a > > >>> > > >>> écrit : > > >>>>>>>>>>> Howdy, > > >>>>>>>>>>> > > >>>>>>>>>>> Cool that you brought up this topic, thanks! > > >>>>> > > >>>>>>>>>>> Well, for start, to not repeat myself, a bit of history: > > >>>>> https://maveniverse.eu/blog/2025/07/02/pom-proliferation-part-1/ > > >>>>> > > >>>>>>>>>>> (note: this is in fact a response to completely unrelated > > >>> > > >>> blog > > >>> > > >>>>>>> entry, > > >>>>>>> > > >>>>>>>>>>> but is good to "cover the grounds" for now) > > >>>>>>>>>>> > > >>>>>>>>>>> In short: what today happens with Maven Central (MC) is > > >>> > > >>> totally > > >>> > > >>>>>>> out of > > >>>>>>> > > >>>>>>>>>>> scope of ASF Maven Project, that created it. > > >>>>>>>>>>> What I also find ironical (or sad) is that project > > >>> > > >>> "causing" MC > > >>> > > >>>>>>> lost > > >>>>>>> > > >>>>>>>>>>> native access to it (while with Nx2 ran OSS/S01 you could > > >>> > > >>> use > > >>> > > >>>>>>>>>>> m-deploy-p just fine, from now on, you cannot). > > >>>>>>>>>>> > > >>>>>>>>>>> Hence, there is no "native" or "out of the box" support for > > >>>>>>> > > >>>>>>> publishing > > >>>>>>> > > >>>>>>>>>>> for Maven right now. > > >>>>>>>>>>> > > >>>>>>>>>>> As you know, there are some solutions offered, that are all > > >>>>>>>>>>> problematic for me as well: > > >>>>>>>>>>> - they either "reinvent" (or force you to) reconfigure > > >>> > > >>> whole > > >>> > > >>>>>> world > > >>>>>> > > >>>>>>> again > > >>>>>>> > > >>>>>>>>>>> - or meddle with your build and have different > > >>> > > >>> requirements you > > >>> > > >>>>>>> need > > >>>>>>> > > >>>>>>>>>>> to implement > > >>>>>>>>>>> > > >>>>>>>>>>> Hence, the thing I'd recommend from maveniverse is Njord: > > >>>>>>>>>>> https://maveniverse.eu/docs/njord/ > > >>>>>>>>>>> > > >>>>>>>>>>> That basically (re) implements what Nx2 had, but locally > > >>> > > >>> and > > >>> > > >>>>> adds > > >>>>> > > >>>>>>>>>>> publishing support as well. > > >>>>>>>>>>> This extension was done to fully container all the issues > > >>>>> > > >>>>> above: > > >>>>>>>>>>> - is not "aggressive", literally steps aside > > >>>>>>>>>>> - does not require to reconfigure your whole build (you can > > >>>>>> > > >>>>>> publish > > >>>>>> > > >>>>>>>>>>> even non integrated projects with it) > > >>>>>>>>>>> - uses Maven and is Maven "native", no parallel worlds > > >>>>>>>>>>> > > >>>>>>>>>>> Of course, Njord does not help with cases like TrinoDB has > > >>>>> > > >>>>> (that > > >>>>> > > >>>>>> is > > >>>>>> > > >>>>>>>>>>> Central Portal server side limitation), > > >>>>>>>>>>> and many other things, but is working for many other > > >>> > > >>> projects. > > >>> > > >>>>>>>>>>> Also, as you mentioned, I created this issue (as Njord > > >>> > > >>> suffers > > >>> > > >>>>>>> from it > > >>>>>>> > > >>>>>>>>>>> as > > >>>>>>>>>>> well): https://github.com/maveniverse/njord/issues/150 > > >>>>>>>>>>> > > >>>>>>>>>>> HTH > > >>>>>>>>>>> Tamas > > >>>>>>>>>>> > > >>>>>>>>>>> On Sun, Jul 6, 2025 at 2:37 PM Jon Harper < > > >>>>>> > > >>>>>> [email protected]> > > >>>>>> > > >>>>>>>> wrote: > > >>>>>>>>>>>> Hi everyone, > > >>>>>>>>>>>> I think it would be very beneficial for the community > > >>> > > >>> that > > >>> > > >>>>> the > > >>>>> > > >>>>>>> maven > > >>>>>>> > > >>>>>>>>>>>> dev team communicates on the current events of the > > >>> > > >>> sunset of > > >>> > > >>>>>>> OSSRH. > > >>>>>>> > > >>>>>>>>>>>> Otherwise, I think there is a big risk of uncertainty and > > >>>>>>> > > >>>>>>> division in > > >>>>>>> > > >>>>>>>>>>>> the community. > > >>>>>>>>>>>> > > >>>>>>>>>>>> Quoting Romain ( > > >>>>>> > > >>>>>> https://lists.apache.org/thread/bf3762lvd8l64hwyny7rnp3m6r852b9h > > >>>>>> > > >>>>>>> ) > > >>>>>>> > > >>>>>>>>>>>> from a year ago > > >>>>>>>>>>>> "most of us using central outside the asf will be > > >>> > > >>> impacted > > >>> > > >>>>>>> sometime > > >>>>>>> > > >>>>>>>>>>>> next year probably" > > >>>>>>>>>>>> > > >>>>>>>>>>>> And now this time has come (note: I shamefully > > >>> > > >>> procrastinated > > >>> > > >>>>>> the > > >>>>>> > > >>>>>>>>>>>> ossrh migration until I was forced to, but like many > > >>> > > >>> people I > > >>> > > >>>>>>>>>>>> guess..). Unfortunately, it coincides with the last > > >>> > > >>> stages of > > >>> > > >>>>>> the > > >>>>>> > > >>>>>>>>>>>> maven 4 release, so I understand that everyone is very > > >>> > > >>> busy > > >>> > > >>>>> at > > >>>>> > > >>>>>>> the > > >>>>>>> > > >>>>>>>>>>>> moment. > > >>>>>>>>>>>> > > >>>>>>>>>>>> Maven is a tool that communicates with the outside > > >>> > > >>> world, so > > >>> > > >>>>> I > > >>>>> > > >>>>>>> would > > >>>>>>> > > >>>>>>>>>>>> think it's legitimate for the maven devs to publicly > > >>> > > >>> express > > >>> > > >>>>>>> their > > >>>>>>> > > >>>>>>>>>>>> guidelines. Unfortunately it's not an easy task (as a > > >>> > > >>> matter > > >>> > > >>>>> of > > >>>>> > > >>>>>>> fact, > > >>>>>>> > > >>>>>>>>>>>> the best resource I currently know for this is the > > >>> > > >>> personal > > >>> > > >>>>>> blog > > >>>>>> > > >>>>>>> of > > >>>>>>> > > >>>>>>>>>>>> Karl Heinz Marbaise), but maybe an email discussion can > > >>> > > >>> lay > > >>> > > >>>>>>> enough > > >>>>>>> > > >>>>>>>>>>>> foundations by gathering many opinions so that a coherent > > >>>>>>> > > >>>>>>> message can > > >>>>>>> > > >>>>>>>>>>>> be sent to the community ? > > >>>>>>>>>>>> > > >>>>>>>>>>>> Aggravating factors in central-publishing-maven-plugin > > >>> > > >>> that > > >>> > > >>>>>> lead > > >>>>>> > > >>>>>>> to > > >>>>>>> > > >>>>>>>>>>>> uncertainty according to me: > > >>>>>>>>>>>> - Similarity with the standard maven-deploy-plugin. > > >>> > > >>> Sonatype > > >>> > > >>>>>>> even has > > >>>>>>> > > >>>>>>>>>>>> a compatibility service but its use is discouraged ("We > > >>> > > >>> hope > > >>> > > >>>>>>> that over > > >>>>>>> > > >>>>>>>>>>>> time plugins will adopt the Portal API rather than rely > > >>> > > >>> on > > >>> > > >>>>> this > > >>>>> > > >>>>>>>>>>>> service" in > > >>> > > >>> > https://central.sonatype.org/publish/publish-portal-ossrh-staging-api/ > > >>> > > >>>>>>>>>>>> ). > > >>>>>>>>>>>> - No public scm system available makes it hard to get > > >>> > > >>> context > > >>> > > >>>>>>>>>>>> information ( > > >>> > > >>> > https://repo1.maven.org/maven2/org/sonatype/central/central-publishing > > >>> > > >>>>>>>>>>>> -m > > >>>>>>>>>>>> a > > >>> > > >>> ven-plugin/0.8.0/central-publishing-maven-plugin-0.8.0.pom > > >>> > > >>>>>> lists > > >>> > > >>> https://github.com/sonatype/central-publishing-maven-plugin > > >>> > > >>>>>> but > > >>>>>> > > >>>>>>> is > > >>>>>>> > > >>>>>>>>>>>> 404). > > >>>>>>>>>>>> (Note: The code is still available in the source jar > > >>>>>>>>>>>> alongside the plugin > > >>> > > >>> > https://repo1.maven.org/maven2/org/sonatype/central/central-publishing > > >>> > > >>>>>>>>>>>> -m > > >>>>>>>>>>>> av > > >>>>>>> > > >>>>>>> > en-plugin/0.8.0/central-publishing-maven-plugin-0.8.0-sources.jar ) > > >>>>>>> > > >>>>>>>>>>>> - central-publishing-maven-plugin uses > > >>>>>>> > > >>>>>>> <extension>true</extension> to > > >>>>>>> > > >>>>>>>>>>>> forcefully remove any invocation of the > > >>> > > >>> maven-deploy-plugin > > >>> > > >>>>>>> which I > > >>>>>>> > > >>>>>>>>>>>> found surprising (aggressive ?) behavior. > > >>>>>>>>>>>> - impossible as of 0.8.0 to use > > >>>>> > > >>>>> central-publishing-maven-plugin > > >>>>> > > >>>>>>> behind > > >>>>>>> > > >>>>>>>>>>>> a corporate proxy which ( by virtue of the http client5 > > >>> > > >>> of > > >>> > > >>>>>> apache > > >>>>>> > > >>>>>>>>>>>> httpcomponents without the extra code required to allow > > >>>>> > > >>>>> proxies > > >>>>> > > >>>>>>> ...) > > >>>>>>> > > >>>>>>>>>>>> - looks like fighting instead of cooperating (even > > >>> > > >>> though the > > >>> > > >>>>>>> plugin > > >>>>>>> > > >>>>>>>>>>>> architecture of maven invites this kind of work, maybe > > >>> > > >>> it's > > >>> > > >>>>>>> better > > >>>>>>> > > >>>>>>>>>>>> when core functionality stays within the maven umbrella > > >>> > > >>> like > > >>> > > >>>>>> the > > >>>>>> > > >>>>>>>>>>>> maven-deploy-plugin?) > > >>>>>>>>>>>> > > >>>>>>>>>>>> What are your thoughts ? Are the recent improvements to > > >>> > > >>> the > > >>> > > >>>>>>>>>>>> maven-deploy-plugin strong enough the try and unite all > > >>>>>>> > > >>>>>>> publishing > > >>>>>>> > > >>>>>>>>>>>> plugins as one ? > > >>>>>>>>>>>> > > >>>>>>>>>>>> Cheers, > > >>>>>>>>>>>> Jon > > >>> > > >>> --------------------------------------------------------------------- > > >>> > > >>>>>>>>>>>> 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] > > >>>>>> > > >>>>>> > --------------------------------------------------------------------- > > >>>>>> > > >>>>>>>>>> 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] > > >>> > > >>> --------------------------------------------------------------------- > > >>> > > >>>>>>>> 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] > > > > > > --------------------------------------------------------------------- > > > 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] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
