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