Hello, just for my understanding: - Does the property reactorProjects[0] hold the projects in reactor build order?
Regards Mirko [0] https://github.com/apache/maven-plugins/blob/trunk/maven-install-plugin/src/main/java/org/apache/maven/plugin/install/InstallMojo.java#L68 On Wed, Feb 5, 2014 at 1:56 PM, Igor Fedorenko <i...@ifedorenko.com> wrote: > Maven first calls #afterProjectsRead(MavenSession), then calculates > reactor build order. So session.getProjects() still returns unsorted > project list during afterProjectsRead, which most likely does not matter > in your case. > > -- > Regards, > Igor > > > On 2/4/2014, 17:47, William Ferguson 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
