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