> -----Original Message----- > From: Brett Porter [mailto:[EMAIL PROTECTED] > Sent: vendredi 19 août 2005 12:39 > To: Maven Developers List > Subject: Re: Processing Order for the m2 Reactor > > so you are saying that the children should build before the parent? > Currently, the parent is considered a dep so it always goes first. > > I see your point, which would mean making the modules dependencies > instead of the parent (though anything aggregating really should use > plugins able to deal with that rather than recursing the subprojects). > It was deliberately building them first so a pom would be installed at > the start, but with the built in pom discovery that is no longer > necessary. > > Anyone else have thoughts?
I have also been a bit troubled by this too. The issues that I see with a parent-build-first strategy are: - It's the opposite of m1 - You can't cd to a module and build it. You need to always build the parent first so when you do development you often forget to republish a modified parent POM. - It doesn't work for aggregation when a parent does something on the result of the children's build, like aggregating children jars in a uberjar, or aggregating javadocs into a single javadoc, etc. Of course, as you mention, module traversal features could be implemented every time in the plugin itself but doesn't it means reimplementing manually the module discovery in each plugin? This is a complex topic though and there are lots of details to take into account. I'm only listing here the issues that I see but I'm pretty sure there are other issues too with doing children-build-first. But it does sounds more logical to me to start as deep as possible and then work up to the top level. It sounds to me as if POM definitions should be done top-down and builds bottom-up... What am I missing (I'm pretty sure I'm missing a lot)? :-) Thanks -Vincent > > - Brett > > Allison, Bob wrote: > > >I have been looking at the order that the reactor processes projects and > >it appears that, unless there is an explicit dependency, processing is > >always done from the top down. I suspect that there are good reasons to > >do things that way, but I can think of a couple instances where > >processing from the bottom up might be better: > >-- A parent project that packages an EAR, where each child project is a > >component to be packaged in the EAR, would work better since the parent > >project could always be sure that the components are freshly-built > >-- The site generation process would be able to pull the > >freshly-completed sites from each module during its own processing > >without requiring the modules to push up to the parent > > > >I did an experiment to change ReactorManager, line 88, to reverse the > >edge between parent and child. This changes passed all of the > >integration tests and did convert the processing to be bottom up. > > > >I'm not sure if this change is a good thing, but it does make the > >reactor work in a manner similar to how the 1.x multiproject plugin > >operates (but of course with better dependency resolution). > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
