Errata: NOT imports, but rather "named capabilities". So now, I'd not let plugins fiddle with imports, but would rather "group" and name elements of extensions.xml
On Fri, Nov 18, 2022 at 7:53 PM Tamás Cservenák <ta...@cservenak.net> wrote: > Now imports. But somewhat "named capabilities". Most of the plugins (vast > majority) would use the default of "*" (give me whatever you have). > > If I look at this file: > > https://github.com/apache/maven/blob/master/maven-core/src/main/resources/META-INF/maven/extension.xml > > I see "capabilities" like: > - m4 api > - m3 api x > - wagon x? > - resolver x > - classworlds x? > - plexus-xml x? <- Guillaume? > - plexus-container x > - jsr330 > - jsr250 > - slf4j > - jansi > > Note: in some future maven 4.5/5/whatever entries marked with "x" are > gone. Those with "?" capabilities are unsure if I am right or not (that > will be gone), Guillaume will chime in hopefully. > > The vast majority of plugins will not bother with these settings at all > (will have default value of "*"). > Some may want to tune it, like not having jsr330 or slf4j, or purist > plugins may ask only for "m4api". > > Point is (whether enum or not) is: > if a plugin asks for capability that maven runtime does not have (for > example m3api in maven 5) -> leads to breakage. > > === > > BUT, I said this would be a "dream" :) Do not stick to it. Am completely > fine with a flag as I described before. > > T > > > On Fri, Nov 18, 2022 at 7:36 PM Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: > >> Guess if you start to enable imports of components outside the API all the >> API work done for m4 disappear and you get back in current state, ie a >> mojo >> is not able to know what it can rely on from maven until we create an enum >> and it would be we put jsr330 (note this one does not mean much since the >> injected type will be the most important), slf4j are part of the API and >> we >> said we don't want that - for goods so sounds like we should stick to the >> API respect IMHO and if needed promote some new API, no? >> >> Romain Manni-Bucau >> @rmannibucau <https://twitter.com/rmannibucau> | Blog >> <https://rmannibucau.metawerx.net/> | Old Blog >> <http://rmannibucau.wordpress.com> | Github < >> https://github.com/rmannibucau> | >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book >> < >> https://www.packtpub.com/application-development/java-ee-8-high-performance >> > >> >> >> Le ven. 18 nov. 2022 à 19:11, Tamás Cservenák <ta...@cservenak.net> a >> écrit : >> >> > Howdy, >> > >> > just to describe a bit what I meant under "reversed flag": >> > >> > default is iWillBeInChargeOfMyComponents=false, Maven4 behaves as today. >> > Plugin classrealm gets (from memory, might be incomplete or wrong): >> > - m4 API >> > - m3 "plugin-api" >> > - javax.inject >> > - resolver api >> > - etc as today >> > >> > consider that MANY plugins have components, and creating components in >> > MAJORITY of plugins is easy and should remain easy (and offered "out of >> the >> > box"). >> > >> > but IF iWillBeInChargeOfMyComponents=true, Maven 4 creates a plugin >> realm >> > that has m4 API accessible ONLY, NOTHING MORE. And in that sandbox, the >> > plugin can do whatever it wants, but still has access to m4 API (that is >> > heaven vs earth when compared to m3 state of affairs). >> > >> > === >> > >> > in future, when we drop m3 support, this could mean: >> > >> > false (default) >> > - m4 API >> > - javax.inject >> > >> > true >> > -m4 API >> > >> > === >> > >> > Dreaming: but what if not a flag, but some filter(s) for "capabilities"? >> > values: >> > - * <- plugin classrealm should have all "capabilities" current Maven >> > runtime provides >> > - m4api <- I want maven 4 api ONLY >> > - m3api, slf4j, jsr330 <- I want to m3 api (would break in m4+ that >> drops >> > m3 backward compat), slf4j logging and would use jsr330 components >> > "capability" >> > >> > But this is getting too wild maybe :) >> > >> > >> > T >> > >> > On Fri, Nov 18, 2022 at 6:34 PM Tamás Cservenák <ta...@cservenak.net> >> > wrote: >> > >> > > Howdy, >> > > >> > > Am -1 on this. We just reached the point to (somewhat) undo the "Maven >> > > downloads the whole world", at least latest plugins by putting Maven >> and >> > > friends in provided scope will not download dozens of versions of >> > > maven-core and friends... If we do this, at one point we would end up >> > with >> > > plugins downloading dozens of DI container (or their versions), as >> even >> > ASF >> > > plugins would not be in "lockstep". >> > > >> > > OTOH, that said, I like the idea of a flag, but I'd reverse it: a flag >> > > that would say maven "I will be in charge of my components" (defaults >> to >> > > false, Maven behaves as today). When true, it would mean Mojo wants to >> > > bootstrap some DI/whatever container of its own, and then, for plugins >> > like >> > > these, Maven could even "narrow" the list of exported classes? (like >> > > javax.inject?) >> > > >> > > T >> > > >> > > On Fri, Nov 18, 2022 at 4:57 PM Guillaume Nodet <gno...@apache.org> >> > wrote: >> > > >> > >> Following up on my previous response, and in a more realistic way >> than >> > >> switching to OSGi, I wonder if we should let maven 4 plugins do their >> > own >> > >> DI injection and only care about the mojos, i.e. not rely on >> sisu/plexus >> > >> to >> > >> create and inject the mojo. Mojos using the v4 api do not need to be >> > >> injected with other components from maven, they should all come from >> the >> > >> api and should be retrieved using Session.getService(xx), or simply >> > using >> > >> session's shortcut methods. The injection of Project and Session is >> not >> > >> controlled by sisu. For the ComponentConfigurator, we could change >> the >> > >> mojo >> > >> descriptor to have the full configuration class name for mojos that >> > >> require >> > >> custom configuration injection, the plugin manager being in charge of >> > >> instantiating this class and using it as a ComponentConfigurator >> (which >> > is >> > >> not part yet of the api btw). >> > >> >> > >> Complex plugins which rely on plexus/sisu to do some custom injection >> > >> would >> > >> have to be changed to do their own DI, maybe using a simple Guice >> setup. >> > >> >> > >> If that sounds like too big a change for those plugins, we may be >> able >> > to >> > >> add a flag on the mojo descriptor so that those v4-enabled mojos >> would >> > >> trigger a DI injection on behalf of the plugin. But if we have to >> > >> implement something like that, I would go for a plain CDI-like api, >> > either >> > >> using guice or another DI library supporting the javax.inject >> package, >> > or >> > >> rather the jakarta.inject package, as it would be nice to switch to >> the >> > >> jakarta version at the same time. Or maybe even plexus if we really >> > need >> > >> to, but with a limited scope, i.e. no visibility on the maven >> > components, >> > >> so that plugins are better decoupled from maven-core. >> > >> >> > >> Thoughts ? >> > >> >> > >> Le jeu. 17 nov. 2022 à 17:48, Guillaume Nodet <gno...@apache.org> a >> > >> écrit : >> > >> >> > >> > I do agree that debugging the provisioning side is *very* >> complicated >> > >> when >> > >> > there's a problem. >> > >> > I'd be happy to get rid of sisu/plexus and use a more simple DI >> > >> framework, >> > >> > at least for simple plugins. >> > >> > However, I definitely don't think pushing OSGi to plugins would be >> a >> > >> good >> > >> > idea : the cost and burden on plugin developers would outweigh the >> > >> benefits. >> > >> > >> > >> > For extensions, and for maven itself, that is a different story >> > though. >> > >> > Maven and extensions could definitely benefit from OSGi, but this >> > would >> > >> be >> > >> > a complete breakage and it would be hard to keep some level of >> > >> > compatibility. >> > >> > >> > >> > Le jeu. 17 nov. 2022 à 17:00, Christoph Läubrich < >> m...@laeubi-soft.de >> > > >> > >> a >> > >> > écrit : >> > >> > >> > >> >> > Guess classrealm is fine for maven, it does not bring much >> issues >> > >> >> >> > >> >> As long as it works, maybe, maybe even if you write a simple maven >> > >> >> plugin, but for any more complex it is just a complete mess. >> > >> >> >> > >> >> Last time I asked on the mailing list how to debug that stuff ... >> > >> >> complete silence ... >> > >> >> >> > >> >> Today I tried to refactor the name of one module of a more complex >> > >> >> maven-plugin (with core extension), now I end up with >> > >> >> >> > >> >> org.apache.maven.InternalErrorException: Internal error: >> > >> >> com.google.inject.ProvisionException: Unable to provision, see the >> > >> >> following errors: >> > >> >> 1) No implementation for org.eclipse.aether.RepositorySystem was >> > bound. >> > >> >> >> > >> >> A whole bunch of stack trace but not a little info why the ***** >> it >> > is >> > >> >> not happy. Now I need to add random "exportedArtifact" / >> > >> >> "exportedPackage" stuff to hope finding out where it has lost a >> > >> >> transitive dependency, also here absolutely no documentation what >> > this >> > >> >> is supposed to do/work exactly beside some introduction that these >> > xml >> > >> >> tags exits and reading the code... or probably add maven-compat >> > >> >> anywhere... or change provided to compile scope (even maven is >> > jelling >> > >> >> at me that's bad and I will be punished soon)... not counting the >> > many >> > >> >> times where I messed up the realms because I accidentally trying >> to >> > use >> > >> >> XppDom objects in extensions and plugins and something between got >> > >> >> messed up. >> > >> >> >> > >> >> With OSGi i get clear errors for missing requirements, I can >> clearly >> > >> >> share API (or declare I don't want to share it) and can reliable >> use >> > it >> > >> >> without classlaoding problems. >> > >> >> If one wan't can even implement service filtering that would hide >> all >> > >> >> "illegal implemented API" ... and you can even make sure API is >> > >> >> (backward) compatible with implementation without waiting for a >> > method >> > >> >> not found exception or alike. >> > >> >> >> > >> >> Beside that I find it often more clear to distinguish between API >> > (that >> > >> >> is only implemented by the framework) and SPI (that might be >> > >> implemented >> > >> >> by extenders). So probably it would be good to have maven-api and >> > >> >> maven-spi (instead of "maven-core") to make this clear. >> > >> >> >> > >> >> Am 16.11.22 um 14:53 schrieb Romain Manni-Bucau: >> > >> >> > Hi, >> > >> >> > >> > >> >> > Guess classrealm is fine for maven, it does not bring much >> issues >> > >> (less >> > >> >> > than OSGi or JPMS to be concrete), the real issue is the >> stability >> > of >> > >> >> the >> > >> >> > exposed API. >> > >> >> > Thanks the hard work Guillaume did on that for maven 4 I guess >> it >> > is >> > >> >> mainly >> > >> >> > a matter of deciding what we do for maven 3. >> > >> >> > Due to the resources and work needed I assume we can just play >> the >> > >> >> > status-quo for maven 3. >> > >> >> > Remaining question is for maven 4 do we drop the compatibilty. I >> > >> don't >> > >> >> like >> > >> >> > much the idea but a compat layer can solve that smoothly for >> maven >> > >> >= 4 >> > >> >> and >> > >> >> > limit the work needed, no? >> > >> >> > >> > >> >> > Romain Manni-Bucau >> > >> >> > @rmannibucau <https://twitter.com/rmannibucau> | Blog >> > >> >> > <https://rmannibucau.metawerx.net/> | Old Blog >> > >> >> > <http://rmannibucau.wordpress.com> | Github < >> > >> >> https://github.com/rmannibucau> | >> > >> >> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book >> > >> >> > < >> > >> >> >> > >> >> > >> https://www.packtpub.com/application-development/java-ee-8-high-performance >> > >> >> > >> > >> >> > >> > >> >> > >> > >> >> > Le mer. 16 nov. 2022 à 13:00, Christoph Läubrich < >> > >> m...@laeubi-soft.de> >> > >> >> a >> > >> >> > écrit : >> > >> >> > >> > >> >> >> If you really like to separate API and get out of the >> > >> ClassRealm-Hell >> > >> >> >> OSGi would be much more suitable: >> > >> >> >> >> > >> >> >> https://issues.apache.org/jira/browse/MNG-7518 >> > >> >> >> >> > >> >> >> Am 16.11.22 um 12:30 schrieb Gary Gregory: >> > >> >> >>> As much as I dislike JPMS, maybe Maven 4 should migrate to >> Java 9 >> > >> or >> > >> >> 11 >> > >> >> >> and >> > >> >> >>> adopt JPMS to better define its public APIs. >> > >> >> >>> >> > >> >> >>> Gary >> > >> >> >>> >> > >> >> >>> On Wed, Nov 16, 2022, 05:06 Tamás Cservenák < >> ta...@cservenak.net >> > > >> > >> >> wrote: >> > >> >> >>> >> > >> >> >>>> Yes, to define rules is quite easy, but to make our users to >> > obey >> > >> >> them >> > >> >> >> is >> > >> >> >>>> tricky :D >> > >> >> >>>> >> > >> >> >>>> In general, I guess, we should. For this reason JapiCmp has >> been >> > >> >> used in >> > >> >> >>>> Resolver since 1.9.0 (as noted on refd page end). >> > >> >> >>>> >> > >> >> >>>> But while this was "kinda simple" to achieve in Resolver, I >> am >> > >> really >> > >> >> >>>> unsure if it is doable in Maven (sans 4 API) :( >> > >> >> >>>> >> > >> >> >>>> Ultimately, this was the whole reason for API: >> > >> >> >>>> - users "grabbed" whatever could get hold on and used >> > >> >> >>>> - maven progress was really hindered by this, as that meant >> > >> modifying >> > >> >> >> (even >> > >> >> >>>> internal) interfaces without breaking clients was >> impossible, so >> > >> we >> > >> >> went >> > >> >> >>>> with tricks, and more tricks and even more tricks that now >> pays >> > >> back. >> > >> >> >>>> >> > >> >> >>>> The other day we had a question on ML about 4-alpha >> > compatibility >> > >> >> >> breakage, >> > >> >> >>>> and from mail it was clear that the package of the referred >> > class >> > >> was >> > >> >> >>>> having "internal" in it. I mean, developers should really >> take >> > >> care >> > >> >> of >> > >> >> >> what >> > >> >> >>>> they import. >> > >> >> >>>> >> > >> >> >>>> This is another huge plus for Takari lifecycle, it FORBIDS >> > >> >> compilation >> > >> >> >>>> against "encapsulated" internal classes.... >> > >> >> >>>> >> > >> >> >>>> >> > >> >> >> >> > >> >> >> > >> >> > >> http://takari.io/book/40-lifecycle.html#enforcing-dependency-usage-during-compilation >> > >> >> >>>> >> > >> >> >>>> T >> > >> >> >>>> >> > >> >> >>>> On Wed, Nov 16, 2022 at 10:44 AM Konrad Windszus < >> > k...@apache.org >> > >> > >> > >> >> >> wrote: >> > >> >> >>>> >> > >> >> >>>>> I guess this is the easy part, the tricky question remains: >> Do >> > we >> > >> >> need >> > >> >> >> to >> > >> >> >>>>> make sure that all Maven 3 API interfaces/classes stay 100% >> > >> >> backwards >> > >> >> >>>>> compatible until we reach 4.100/5.0/whatever? >> > >> >> >>>>> >> > >> >> >>>>> This wasn't handled consistently in master till now, e.g. >> the >> > >> >> classes >> > >> >> >>>>> generated from >> > >> >> >>>>> >> > >> >> >>>> >> > >> >> >> >> > >> >> >> > >> >> > >> https://github.com/apache/maven/blob/master/maven-plugin-api/src/main/mdo/lifecycle.mdo >> > >> >> >>>>> are now immutable, i.e. lack setter methods in Maven 4. >> > >> >> >>>>> My change in >> > >> >> >>>>> >> > >> >> >>>> >> > >> >> >> >> > >> >> >> > >> >> > >> https://github.com/apache/maven/pull/827/files#diff-2324c8cead0ad922c829a8ca450764aa149d6efdfe7f841e64210f20efd148acR77 >> > >> >> >>>>> was not backwards compatible (removed a method on an >> interface >> > >> which >> > >> >> >> may >> > >> >> >>>>> have been implemented by extensions...) >> > >> >> >>>>> >> > >> >> >>>>> Konrad >> > >> >> >>>>> >> > >> >> >>>>> On 2022/11/16 09:35:15 Tamás Cservenák wrote: >> > >> >> >>>>>> Unsure we want to deprecate all of Maven :) >> > >> >> >>>>>> >> > >> >> >>>>>> But yes, in general, 3.x "Maven API" was "all that users >> can >> > >> grab" >> > >> >> >>>> sadly, >> > >> >> >>>>>> and is probably our major source of problems and reason we >> > >> started >> > >> >> >>>> Maven >> > >> >> >>>>> 4 >> > >> >> >>>>>> API. >> > >> >> >>>>>> >> > >> >> >>>>>> IMO, I'd consider them as "whole", and just say "starting >> with >> > >> >> Maven >> > >> >> >>>>>> 4.100/5.0/whatever" the maven-core (any class out of it) is >> > NOT >> > >> >> >>>>> ACCESSIBLE >> > >> >> >>>>>> ANYMORE FROM PLUGINS. >> > >> >> >>>>>> And done. >> > >> >> >>>>>> >> > >> >> >>>>>> Just as an example, here is what Maven Resolver has to say >> > about >> > >> >> same >> > >> >> >>>>> topic >> > >> >> >>>>>> (part of not-yet-released, vote is in process 1.9.1 >> version): >> > >> >> >>>>>> >> > >> >> >>>>> >> > >> >> >>>> >> > >> >> >> >> > >> >> >> > >> >> > >> https://maven.apache.org/resolver-archives/resolver-LATEST/api-compatibility.html >> > >> >> >>>>>> >> > >> >> >>>>>> HTH >> > >> >> >>>>>> T >> > >> >> >>>>>> >> > >> >> >>>>>> On Wed, Nov 16, 2022 at 10:26 AM Konrad Windszus < >> > >> k...@apache.org> >> > >> >> >>>>> wrote: >> > >> >> >>>>>> >> > >> >> >>>>>>> I see now there is already >> > >> >> >>>>>>> >> > >> >> >>>>> >> > >> >> >>>> >> > >> >> >> >> > >> >> >> > >> >> > >> https://github.com/apache/maven/blob/master/api/maven-api-meta/src/main/java/org/apache/maven/api/annotations/Provider.java >> > >> >> >>>>>>> but to me the javadoc is not explicit enough. It should >> > state: >> > >> >> Only >> > >> >> >>>>> Maven >> > >> >> >>>>>>> is allowed to implement/extend types with this annotation. >> > >> >> >>>>>>> >> > >> >> >>>>>>> Konrad >> > >> >> >>>>>>> >> > >> >> >>>>>>> On 2022/11/16 09:20:11 Konrad Windszus wrote: >> > >> >> >>>>>>>> Hi, >> > >> >> >>>>>>>> Unfortunately Maven 3 didn’t define a proper API. In >> effect >> > >> >> >>>>> everything >> > >> >> >>>>>>> somehow exposed through class loaders was considered API >> by >> > >> >> >>>>>>> plugin/extension developers. >> > >> >> >>>>>>>> For Maven 4 a completely separate API was established in >> > >> package >> > >> >> >>>>>>> “org.apache.maven.api”, but what about the old packages >> used >> > >> and >> > >> >> >>>>> exported >> > >> >> >>>>>>> in Maven 3? >> > >> >> >>>>>>>> >> > >> >> >>>>>>>> For example in the context of >> > >> >> >>>>>>> https://issues.apache.org/jira/browse/MNG-7588 < >> > >> >> >>>>>>> https://issues.apache.org/jira/browse/MNG-7588> I want to >> > >> evolve >> > >> >> the >> > >> >> >>>>>>> package “org.apache.maven.plugin.descriptor”. >> > >> >> >>>>>>>> We already figured out that this particular package >> > (although >> > >> not >> > >> >> >>>>> part >> > >> >> >>>>>>> of the Maven 4 API) is used from both Maven Core as well >> as >> > >> Maven >> > >> >> >>>>> Plugin >> > >> >> >>>>>>> Tools, therefore this probably needs to stay backwards >> > >> compatible. >> > >> >> >>>>>>>> What about others like >> > >> >> >>>>>>> >> > >> >> >>>>> >> > >> >> >>>> >> > >> >> >> >> > >> >> >> > >> >> > >> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java >> > >> >> >>>>> ? >> > >> >> >>>>>>> < >> > >> >> >>>>>>> >> > >> >> >>>>> >> > >> >> >>>> >> > >> >> >> >> > >> >> >> > >> >> > >> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java >> > >> >> >>>>>>> ?> >> > >> >> >>>>>>>> This interface should IMHO never been implemented outside >> > >> Maven >> > >> >> >>>> Core >> > >> >> >>>>> but >> > >> >> >>>>>>> in fact it was exposed to all plugins/extensions (via >> > >> >> >>>>>>> >> > >> >> >>>>> >> > >> >> >>>> >> > >> >> >> >> > >> >> >> > >> >> > >> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40 >> > >> >> >>>>>>> < >> > >> >> >>>>>>> >> > >> >> >>>>> >> > >> >> >>>> >> > >> >> >> >> > >> >> >> > >> >> > >> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40 >> > >> >> >>>>>>>> ). >> > >> >> >>>>>>>> >> > >> >> >>>>>>>> There are three options coming to my mind: >> > >> >> >>>>>>>> >> > >> >> >>>>>>>> 1. Deprecate the interfaces we don’t consider API and >> create >> > >> new >> > >> >> >>>> ones >> > >> >> >>>>>>> for Maven 4 which are not exported! >> > >> >> >>>>>>>> 2. Modify the existing interfaces in a backwards >> compatible >> > >> way >> > >> >> >>>> (but >> > >> >> >>>>>>> somehow add a marker that they should not be implemented >> > >> outside >> > >> >> >>>> core) >> > >> >> >>>>>>>> 3. Modify the existing interfaces in a backwards >> compatible >> > >> way >> > >> >> >>>> (but >> > >> >> >>>>>>> somehow add a marker that they should not be implemented >> > >> outside >> > >> >> >>>> core) >> > >> >> >>>>>>>> >> > >> >> >>>>>>>> For all three options we somehow need to come up with a >> list >> > >> of >> > >> >> >>>>>>> classes/interfaces currently being exported through the >> API >> > >> class >> > >> >> >>>>> loader, >> > >> >> >>>>>>> which should be considered private and agree on an >> > >> >> Annotation/Javadoc >> > >> >> >>>>> for >> > >> >> >>>>>>> that (something like >> > >> >> >>>>>>> >> > >> >> >>>>> >> > >> >> >>>> >> > >> >> >> >> > >> >> >> > >> >> > >> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29 >> > >> >> >>>>>>> < >> > >> >> >>>>>>> >> > >> >> >>>>> >> > >> >> >>>> >> > >> >> >> >> > >> >> >> > >> >> > >> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29 >> > >> >> >>>>>> >> > >> >> >>>>>>> or >> > https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution >> > >> < >> > >> >> >>>>>>> >> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution> >> > >> >> >>>>>>>> >> > >> >> >>>>>>>> WDYT? >> > >> >> >>>>>>>> >> > >> >> >>>>>>>> Konrad >> > >> >> >>>>>>>> >> > >> >> >>>>>>>> >> > >> >> >>>>>>> >> > >> >> >>>>>>> >> > >> >> >> --------------------------------------------------------------------- >> > >> >> >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> > >> >> >>>>>>> For additional commands, e-mail: >> dev-h...@maven.apache.org >> > >> >> >>>>>>> >> > >> >> >>>>>>> >> > >> >> >>>>>> >> > >> >> >>>>> >> > >> >> >>>>> >> > >> >> >> --------------------------------------------------------------------- >> > >> >> >>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> > >> >> >>>>> For additional commands, e-mail: dev-h...@maven.apache.org >> > >> >> >>>>> >> > >> >> >>>>> >> > >> >> >>>> >> > >> >> >>> >> > >> >> >> >> > >> >> >> >> > >> --------------------------------------------------------------------- >> > >> >> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> > >> >> >> For additional commands, e-mail: dev-h...@maven.apache.org >> > >> >> >> >> > >> >> >> >> > >> >> > >> > >> >> >> > >> >> >> --------------------------------------------------------------------- >> > >> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> > >> >> For additional commands, e-mail: dev-h...@maven.apache.org >> > >> >> >> > >> >> >> > >> > >> > >> > -- >> > >> > ------------------------ >> > >> > Guillaume Nodet >> > >> > >> > >> > >> > >> >> > >> -- >> > >> ------------------------ >> > >> Guillaume Nodet >> > >> >> > > >> > >> >
