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