Do you think this will also include the build context mechanics we talked about a long time ago? Where mojo's can communicate to each other a map of either status or configuration settings through some third party mechanism, perhaps the build plan this talks about. I seem to remember you putting some of that into trunk already but I could be wrong...anyway, that build context material would definitely have impact on this deterministic lifecycle your talking about.
jesse On Jan 29, 2008 3:59 PM, John Casey <[EMAIL PROTECTED]> wrote: > Right...I guess it'd help to include the URL: > > http://docs.codehaus.org/display/MAVEN/Deterministic+Lifecycle+Planning > > Thanks! > > -john > > On Jan 29, 2008, at 4:58 PM, John Casey wrote: > > > Hi all, > > > > I've written up the new features present in the refactored > > lifecycle support for 2.1, if anyone is interested in reading it. > > I'd like to hear what you all think, particularly about the > > emerging discussion of aggregator plugins, pre-exec "plugins", and > > such taking place on the page comments. > > > > In brief, we have numerous problems with aggregator plugins, > > whether you're talking about binding these to a lifecycle phase, > > resolving dependencies of these plugins that actually are present > > in the current reactor, timing of execution (particularly in > > multimodule builds where the plugin needs the output of module > > builds, see the assembly plugin outstanding bugs for this one), and > > more. In addition, there has been an expressed need for a sort of > > pre-execution phase that would allow plugins to manipulate > > dependency lists, mojo bindings, etc. before the build proper > > starts. Finally, there is some discussion about mojos that can > > conditionally choose to fork a nested execution or not, depending > > on how they're used...which also brings up the idea of letting a > > mojo discover where and how it's being used. > > > > IMO, these issues represent the next iteration of Maven build > > definition. They are the next frontier for the work we're trying to > > do in Maven in many ways, and it seems like they deserve a healthy > > design discussion each. In the case of aggregator plugins and the > > pre-execution phase, it may make more sense to go back to first > > principles and see whether we can come up with a single replacement > > solution to aggregators that would address both types of problem. > > > > Please comment if you have an opinion on this. > > > > Thanks, > > > > -john > > > > --- > > John Casey > > Committer and PMC Member, Apache Maven > > mail: jdcasey at commonjava dot org > > blog: http://www.ejlife.net/blogs/john > > rss: http://feeds.feedburner.com/ejlife/john > > > > > > --- > John Casey > Committer and PMC Member, Apache Maven > mail: jdcasey at commonjava dot org > blog: http://www.ejlife.net/blogs/john > rss: http://feeds.feedburner.com/ejlife/john > > > -- jesse mcconnell [EMAIL PROTECTED]
