Thanks very much for your help with this Igor. Providing a dummy classes.jar was enough to get everything up and running. But it really does feel like a hack. The hack is going to buy us some time, but I'd like to construct a proper solution (if such a thing exists).
Wrt to the ArtifactHandler for AAR artifacts. Could you expand on that. Would this be the correct approach to handling artifacts that potentially contain other artifacts/resources? Where should I start in going down this path? William On Wed, Feb 5, 2014 at 11:11 PM, Igor Fedorenko <i...@ifedorenko.com> wrote: > What scope do you use for these dependencies? I thought Maven allowed > folders for system-scoped dependencies, but I can be wrong. Maybe it is > possible to fake this by creating empty jar from the lifecycle > participant and then replace it with the real thing during the build. > > My only other idea is to extend ArtifactHandler API to directly support > "AAR" usecase, i.e. when dependency is not added to classpath directly > but something is extracted from the dependency first and that extracted > file/directory is added to classpath instead. > > -- > Regards, > Igor > > > On 2/5/2014, 1:19, William Ferguson wrote: > >> Mmm I'm struggling to get the hack work. >> >> The problem I am facing is that >> >> 1. the LifeCycleParticipant adds the location at which the Aar classes >> >> are to be extracted to the classpath. >> 2. the Aar classes are extracted by the GenerateSourcesMojo to the >> target folder >> 3. But (2) never happens because Maven throws a >> >> LifeCycleExecutionException as soon as I execute a phase that requires >> dependency resolution. It appears to do dep resolution prior to >> executing >> any phases and it requires that the dependency physically exist. So it >> throws an Exception because the Aar classes haven't been extracted >> yet. >> Build output below. >> >> Any ideas? >> >> >> [INFO] Error stacktraces are turned on. >> [INFO] Scanning for projects... >> [INFO] >> [INFO] AMLP afterProjectsRead >> [INFO] AMLP afterProjectsRead >> [INFO] AMLP afterProjectsRead >> [INFO] >> [INFO] CurrentProject=MavenProject: >> com.jayway.maven.plugins.android.generation2.samples.libraryprojects: >> libraryprojects-aar-from-aar:1.0.0-SNAPSHOT >> @ >> C:\OpenSource\maven-android-plugin-samples\libraryprojects\ >> libraryprojects-aar-from-aar\pom.xml >> [INFO] >> [INFO] >> project=com.jayway.maven.plugins.android.generation2. >> samples.libraryprojects:libraryprojects-aar-from-aar:aar:1.0.0-SNAPSHOT >> [INFO] projects deps: : >> [com.jayway.maven.plugins.android.generation2.samples.libraryprojects: >> libraryprojects-aar1:aar:1.0.0-SNAPSHOT:compile] >> [INFO] Adding to classpath : >> com.jayway.maven.plugins.android.generation2.samples.libraryprojects: >> libraryprojects-aar1:aar:1.0.0-SNAPSHOT:compile >> [INFO] : >> C:\OpenSource\maven-android-plugin-samples\libraryprojects\ >> libraryprojects-aar-from-aar\target\unpacked-lib-classes\ >> libraryprojects-aar1 >> [INFO] >> >> [INFO] >> ------------------------------------------------------------------------ >> [INFO] Building Library Projects - AAR from AAR 1.0.0-SNAPSHOT >> [INFO] >> ------------------------------------------------------------------------ >> [INFO] >> ------------------------------------------------------------------------ >> [INFO] BUILD FAILURE >> [INFO] >> ------------------------------------------------------------------------ >> [INFO] Total time: 1.797s >> [INFO] Finished at: Wed Feb 05 15:45:41 EST 2014 >> [INFO] Final Memory: 9M/110M >> [INFO] >> ------------------------------------------------------------------------ >> [ERROR] Failed to execute goal on project libraryprojects-aar-from-aar: >> Could not resolve dependencies for project >> com.jayway.maven.plugins.android.generation2.samples.libraryprojects: >> libraryprojects-aar-from-aar:aar:1.0.0-SNAPSHOT: >> Could not find artifact >> com.jayway.maven.plugins.android.generation2.samples.libraryprojects: >> libraryprojects-aar1:jar:1.0.0-SNAPSHOT >> at specified path >> C:\OpenSource\maven-android-plugin-samples\libraryprojects\ >> libraryprojects-aar-from-aar\target\unpacked-lib-classes\ >> libraryprojects-aar1 >> -> [Help 1] >> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute >> goal on project libraryprojects-aar-from-aar: Could not resolve >> dependencies for project >> com.jayway.maven.plugins.android.generation2.samples.libraryprojects: >> libraryprojects-aar-from-aar:aar:1.0.0-SNAPSHOT: >> Could not find artifact >> com.jayway.maven.plugins.android.generation2.samples.libraryprojects: >> libraryprojects-aar1:jar:1.0.0-SNAPSHOT >> at specified path >> C:\OpenSource\maven-android-plugin-samples\libraryprojects\ >> libraryprojects-aar-from-aar\target\unpacked-lib-classes\ >> libraryprojects-aar1 >> at >> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver. >> getDependencies(LifecycleDependencyResolver.java:220) >> at >> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver. >> resolveProjectDependencies(LifecycleDependencyResolver.java:127) >> at >> org.apache.maven.lifecycle.internal.MojoExecutor. >> ensureDependenciesAreResolved(MojoExecutor.java:257) >> at >> org.apache.maven.lifecycle.internal.MojoExecutor.execute( >> MojoExecutor.java:200) >> at >> org.apache.maven.lifecycle.internal.MojoExecutor.execute( >> MojoExecutor.java:153) >> at >> org.apache.maven.lifecycle.internal.MojoExecutor.execute( >> MojoExecutor.java:145) >> at >> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject( >> LifecycleModuleBuilder.java:84) >> at >> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject( >> LifecycleModuleBuilder.java:59) >> at >> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild( >> LifecycleStarter.java:183) >> at >> org.apache.maven.lifecycle.internal.LifecycleStarter. >> execute(LifecycleStarter.java:161) >> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317) >> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152) >> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555) >> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214) >> at org.apache.maven.cli.MavenCli.main(MavenCli.java:158) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke( >> NativeMethodAccessorImpl.java:39) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke( >> DelegatingMethodAccessorImpl.java:25) >> at java.lang.reflect.Method.invoke(Method.java:597) >> at >> org.codehaus.plexus.classworlds.launcher.Launcher. >> launchEnhanced(Launcher.java:289) >> at >> org.codehaus.plexus.classworlds.launcher.Launcher. >> launch(Launcher.java:229) >> at >> org.codehaus.plexus.classworlds.launcher.Launcher. >> mainWithExitCode(Launcher.java:415) >> at org.codehaus.plexus.classworlds.launcher.Launcher. >> main(Launcher.java:356) >> Caused by: org.apache.maven.project.DependencyResolutionException: Could >> not resolve dependencies for project >> com.jayway.maven.plugins.android.generation2.samples.libraryprojects: >> libraryprojects-aar-from-aar:aar:1.0.0-SNAPSHOT: >> Could not find artifact >> com.jayway.maven.plugins.android.generation2.samples.libraryprojects: >> libraryprojects-aar1:jar:1.0.0-SNAPSHOT >> at specified path >> C:\OpenSource\maven-android-plugin-samples\libraryprojects\ >> libraryprojects-aar-from-aar\target\unpacked-lib-classes\ >> libraryprojects-aar1 >> at >> org.apache.maven.project.DefaultProjectDependenciesResolver.resolve( >> DefaultProjectDependenciesResolver.java:198) >> at >> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver. >> getDependencies(LifecycleDependencyResolver.java:195) >> ... 22 more >> Caused by: org.eclipse.aether.resolution.DependencyResolutionException: >> Could not find artifact >> com.jayway.maven.plugins.android.generation2.samples.libraryprojects: >> libraryprojects-aar1:jar:1.0.0-SNAPSHOT >> at specified path >> C:\OpenSource\maven-android-plugin-samples\libraryprojects\ >> libraryprojects-aar-from-aar\target\unpacked-lib-classes\ >> libraryprojects-aar1 >> at >> org.eclipse.aether.internal.impl.DefaultRepositorySystem. >> resolveDependencies(DefaultRepositorySystem.java:384) >> at >> org.apache.maven.project.DefaultProjectDependenciesResolver.resolve( >> DefaultProjectDependenciesResolver.java:192) >> ... 23 more >> Caused by: org.eclipse.aether.resolution.ArtifactResolutionException: >> Could >> not find artifact >> com.jayway.maven.plugins.android.generation2.samples.libraryprojects: >> libraryprojects-aar1:jar:1.0.0-SNAPSHOT >> at specified path >> C:\OpenSource\maven-android-plugin-samples\libraryprojects\ >> libraryprojects-aar-from-aar\target\unpacked-lib-classes\ >> libraryprojects-aar1 >> at >> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve( >> DefaultArtifactResolver.java:459) >> at >> org.eclipse.aether.internal.impl.DefaultArtifactResolver. >> resolveArtifacts(DefaultArtifactResolver.java:262) >> at >> org.eclipse.aether.internal.impl.DefaultRepositorySystem. >> resolveDependencies(DefaultRepositorySystem.java:367) >> ... 24 more >> Caused by: org.eclipse.aether.transfer.ArtifactNotFoundException: Could >> not >> find artifact >> com.jayway.maven.plugins.android.generation2.samples.libraryprojects: >> libraryprojects-aar1:jar:1.0.0-SNAPSHOT >> at specified path >> C:\OpenSource\maven-android-plugin-samples\libraryprojects\ >> libraryprojects-aar-from-aar\target\unpacked-lib-classes\ >> libraryprojects-aar1 >> at >> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve( >> DefaultArtifactResolver.java:302) >> ... 26 more >> >> >> >> >> >> William >> >> >> On Wed, Feb 5, 2014 at 8:47 AM, William Ferguson < >> william.fergu...@xandar.com.au> wrote: >> >> Can you explain the need to establish the reactor build order? I had >>> expected session.getProjects() to have returned modules in the order they >>> are defined. Are you saying that is not the case and that it would need >>> to >>> be configured by the LifeCycleParticipant? >>> >>> I think I can make the hack work. So I'll go with that for now. But I'd >>> like to be able to annotate that with an issue number if there are plans >>> to >>> enhance the API on this front so that we know what and when to replace. >>> >>> I'd love to help enhance Maven (I have plenty to pay back for the hours >>> it >>> has saved me over the years) but I don't have the band width right now >>> and >>> I also don't feel like I have a good enough understanding of the Maven >>> core. But as I said before if you think this is a worthwhile enterprise >>> then help me create an issue that spells out what you think needs doing >>> and >>> I'll try to get back to it in a couple of months. >>> >>> William >>> >>> >>> >>> On Tue, Feb 4, 2014 at 10:39 PM, Igor Fedorenko <i...@ifedorenko.com >>> >wrote: >>> >>> >>>> On 2/4/2014, 1:06, William Ferguson wrote: >>>> >>>> OK, I'm getting the dependencies to resolve and I can amend the >>>>> classpath, >>>>> but I think I've hit a road block for multi module builds. >>>>> >>>>> LifeCycleParticipant is only ever called once at the root. This means >>>>> that >>>>> if I have a project with 2 modules where ModuleB depends on ModuleA >>>>> then >>>>> I'm not going to be able extract and add ModuleA and it's classes when >>>>> the >>>>> LifeCycleParticipant executes because ModuleA will not have been built >>>>> yet. >>>>> >>>>> Is there some way to get the LifeCycleParticipant called for every >>>>> module >>>>> of the build? >>>>> >>>>> >>>>> Looks like there are two related but distinct concerns there. >>>> >>>> First, it is necessary to establish reactor build order. This must >>>> happen before actual build starts and lifecycle participant provides a >>>> way to do this. >>>> >>>> Second, it is necessary to resolve dependencies among reactor modules. >>>> This has to happen as part of the build itself and I don't think there >>>> is an API for that yet. >>>> >>>> One hack-ish way to workaround this is to resolve reactor dependencies >>>> is to create empty directories from lifecycle participant, >>>> ModuleA/target/something in your case, and make sure ModuleA's build >>>> populates the directory with expected files. >>>> >>>> Proper solution requires changes to maven core. I can provide some >>>> pointers if you want to try this. >>>> >>>> -- >>>> Regards, >>>> Igor >>>> >>>> >>>> William >>>> >>>>> >>>>> William >>>>> >>>>> >>>>> On Tue, Feb 4, 2014 at 12:46 PM, William Ferguson < >>>>> william.fergu...@xandar.com.au> wrote: >>>>> >>>>> Igor, >>>>> >>>>>> >>>>>> I've worked out how to modify the project classpath (pretty trivial). >>>>>> But >>>>>> I'm struggling to get the project dependencies resolved during >>>>>> LifeCycleParticipant#afterProjectsRead. >>>>>> >>>>>> I tried using the TychoDependencyResolver to #setupProject and >>>>>> #resolveProject but that isn't causing the projects dependencies to >>>>>> get >>>>>> resolved. I'm not sure what I'm missing. >>>>>> >>>>>> I've created a cut down project dep-resolution-plugin at >>>>>> https://github.com/william-ferguson-au/dep-resolution-plugin.git >>>>>> And a project that tests that plugin at >>>>>> https://github.com/william-ferguson-au/dep-resolution-plugin-test.git >>>>>> If you could have a look and point out what it is I'm missing I'd be >>>>>> most >>>>>> grateful. >>>>>> >>>>>> William >>>>>> >>>>>> >>>>>> >>>>>> On Sat, Jan 25, 2014 at 6:57 AM, William Ferguson < >>>>>> william.fergu...@xandar.com.au> wrote: >>>>>> >>>>>> Maven 3.1.1 official, and all the plugin dependencies are 3.,1.1 >>>>>> too. >>>>>> >>>>>>> >>>>>>> I'll trying switching to the annotations. Javadoc annotations were >>>>>>> just >>>>>>> for conformity with the rest of the project. >>>>>>> >>>>>>> If that doesn't work, I'll put together a cut down example. >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> William >>>>>>> >>>>>>> >>>>>>> On Thu, Jan 23, 2014 at 9:43 PM, Igor Fedorenko <i...@ifedorenko.com >>>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>> >>>>>>> No, no tricks, as far as I know Plexus (and now Sisu/Guice) only >>>>>>> >>>>>>>> inject >>>>>>>> fully configured components. so the behaviour you describe is rather >>>>>>>> odd. >>>>>>>> >>>>>>>> What version of Maven do you use? Is it official distribution from >>>>>>>> Apache or something you built locally? >>>>>>>> >>>>>>>> Not likely related, but I haven't used javadoc plexus annotations in >>>>>>>> ages. Any particular reason you don't want to use java 5 @Component? >>>>>>>> >>>>>>>> In any case, if you can provide small standalone example that shows >>>>>>>> the >>>>>>>> problem, I can try to see what's going on there. >>>>>>>> >>>>>>>> -- >>>>>>>> Regards, >>>>>>>> Igor >>>>>>>> >>>>>>>> >>>>>>>> On 1/23/2014, 0:54, William Ferguson wrote: >>>>>>>> >>>>>>>> Igor, >>>>>>>> >>>>>>>>> >>>>>>>>> I'm having some difficulty getting the LifecycleParticipant to >>>>>>>>> resolve >>>>>>>>> Maven components. >>>>>>>>> >>>>>>>>> In particular, the org.apache.maven.project. >>>>>>>>> ProjectDependenciesResolver. >>>>>>>>> While it gets resolved, none of it's internal attributes get >>>>>>>>> resolved. >>>>>>>>> So >>>>>>>>> calls to projectDependenciesResolver.resolve crash with NPEs >>>>>>>>> because >>>>>>>>> DefaultProjectDependenciesResolver#logger or #repoSystem is not >>>>>>>>> initialised. >>>>>>>>> >>>>>>>>> /** >>>>>>>>> * @component >>>>>>>>> * @readonly >>>>>>>>> * @required >>>>>>>>> */ >>>>>>>>> protected ProjectDependenciesResolver >>>>>>>>> projectDependenciesResolver; >>>>>>>>> >>>>>>>>> Is there some special trick to getting components fully initialised >>>>>>>>> in a >>>>>>>>> LifecycleParticipant? >>>>>>>>> >>>>>>>>> William >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Jan 21, 2014 at 12:21 AM, Igor Fedorenko < >>>>>>>>> i...@ifedorenko.com >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Here is Tycho lifecycle participant [1] and here is the code >>>>>>>>> that >>>>>>>>> >>>>>>>>> injects new dependencies in MavenProject instances [2]. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> [1] http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/ >>>>>>>>>> tree/tycho-core/src/main/java/org/eclipse/tycho/core/maven/ >>>>>>>>>> TychoMavenLifecycleParticipant.java?h=tycho-0.19.x >>>>>>>>>> [2] http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/ >>>>>>>>>> tree/tycho-core/src/main/java/org/eclipse/tycho/core/maven/ >>>>>>>>>> MavenDependencyInjector.java?h=tycho-0.19.x >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Regards, >>>>>>>>>> Igor >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 1/20/2014, 8:21, William Ferguson wrote: >>>>>>>>>> >>>>>>>>>> Thanks Igor, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> could you give me a link to an example or some code that >>>>>>>>>>> >>>>>>>>>>> - Utilises AbstractMavenLifecycleParticip >>>>>>>>>>> ant#afterProjectsRead >>>>>>>>>>> - How to manipulate the project <dependencies> from there. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I found an example example by Brett Porter, but the doco is >>>>>>>>>>> pretty >>>>>>>>>>> thin >>>>>>>>>>> and >>>>>>>>>>> I can't see how I would go about inject extra elements into the >>>>>>>>>>> classpath >>>>>>>>>>> from there. >>>>>>>>>>> >>>>>>>>>>> William >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Mon, Jan 20, 2014 at 10:47 PM, Igor Fedorenko < >>>>>>>>>>> i...@ifedorenko.com >>>>>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> There is probably more ways to do this, but you can >>>>>>>>>>> implement >>>>>>>>>>> >>>>>>>>>>> AbstractMavenLifecycleParticipant#afterProjectsRead to >>>>>>>>>>> manipulate >>>>>>>>>>> >>>>>>>>>>>> project <dependencies>. This is what we do in Tycho, where we >>>>>>>>>>>> resolve >>>>>>>>>>>> project OSGi dependencies in AbstractMavenLifecycleParticipant >>>>>>>>>>>> and >>>>>>>>>>>> then >>>>>>>>>>>> inject that into Maven project model as system scoped maven >>>>>>>>>>>> dependencies. >>>>>>>>>>>> >>>>>>>>>>>> I also think your usecase highlights general deficiency with >>>>>>>>>>>> current >>>>>>>>>>>> dependency model. Since you have to add classpath elements >>>>>>>>>>>> dynamically, >>>>>>>>>>>> these elements are not visible to maven-based tools like m2e >>>>>>>>>>>> without >>>>>>>>>>>> additional effort on the tools part. I think it will be useful >>>>>>>>>>>> to >>>>>>>>>>>> extend >>>>>>>>>>>> <dependency> element syntax to allow references for nested >>>>>>>>>>>> archive entries, i.e. "dependency on classes jar nested within >>>>>>>>>>>> this >>>>>>>>>>>> AAR >>>>>>>>>>>> archive". >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Regards, >>>>>>>>>>>> Igor >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 1/20/2014, 7:00, William Ferguson wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I realise this question isn't exactly related to dev within the >>>>>>>>>>>>> Maven >>>>>>>>>>>>> components, but it is about developing a Mojo using components >>>>>>>>>>>>> that >>>>>>>>>>>>> have >>>>>>>>>>>>> to >>>>>>>>>>>>> be pretty central and don't appear to be obviously documented >>>>>>>>>>>>> anywhere. >>>>>>>>>>>>> And >>>>>>>>>>>>> I ahve asked on maven-users without much luck. >>>>>>>>>>>>> >>>>>>>>>>>>> As part of the android-maven-plugin we have a Mojo which needs >>>>>>>>>>>>> to >>>>>>>>>>>>> add an >>>>>>>>>>>>> element to the compile time classpath for future Mojos >>>>>>>>>>>>> (specifically the >>>>>>>>>>>>> maven-compiler-plugin). >>>>>>>>>>>>> >>>>>>>>>>>>> Project has dependencies on artifacts of type AAR (Android >>>>>>>>>>>>> archive >>>>>>>>>>>>> - an >>>>>>>>>>>>> archive that contains several sub-artifacts including a classes >>>>>>>>>>>>> jar). >>>>>>>>>>>>> >>>>>>>>>>>>> Our Mojo unpacks the AAR artifacts and makes the sub-artifacts >>>>>>>>>>>>> available >>>>>>>>>>>>> to >>>>>>>>>>>>> other build components. >>>>>>>>>>>>> >>>>>>>>>>>>> One of those build components is the maven-compiler-plugin. We >>>>>>>>>>>>> want >>>>>>>>>>>>> to >>>>>>>>>>>>> add >>>>>>>>>>>>> the classes contained in the AAR dependencies to the compile >>>>>>>>>>>>> classpath >>>>>>>>>>>>> so >>>>>>>>>>>>> that the maven-compiler-plugin can compile our classes against >>>>>>>>>>>>> the >>>>>>>>>>>>> classes >>>>>>>>>>>>> from the AARs. >>>>>>>>>>>>> >>>>>>>>>>>>> How do we do that? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> William >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> ------------------------------ >>>>>>>>>>>>> ------------------------------ >>>>>>>>>>>>> --------- >>>>>>>>>>>>> >>>>>>>>>>>>> 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 >>>> >>>> >>>> >>> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
