Yes. On Feb 5, 2014, at 4:05 PM, Mirko Friedenhagen <mfriedenha...@gmail.com> wrote:
> 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 > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io --------------------------------------------------------- the course of true love never did run smooth ... -- Shakespeare
