well, when your working with something that will try and predetermine how and when plugins will run and you have something like build context/state in play then plugins will be able to turn themselves off depending on build state based on the context of the build up to that point...which kinda interfers with the overall build plan...at least in deterministically knowing what would happen first
jesse On Jan 30, 2008 1:45 PM, John Casey <[EMAIL PROTECTED]> wrote: > How do you see that impacting the lifecycle stuff, out of curiosity? > > I did put the build context into trunk, but wound up taking it back > out because it wasn't implemented very well, and was leading to a > proliferation of separate, threadlocal-driven storage classes. I've > been thinking for awhile now that it doesn't matter how much we > revamp the actual apis, we're going to be left with a need to access > the current build-state from components that have no direct access to > the parts of Maven they need, because of an api bottleneck like > passing through the ArtifactMetadataSource interface to bridge > together MavenMetadataSource and MavenProjectBuilder. I've been > thinking about this more in terms of a plexus component that contains > the build state and uses a per-thread instantiation strategy (doesn't > exist yet)...but I don't have anything concrete yet. > > -j > > On Jan 30, 2008, at 2:17 PM, Jesse McConnell wrote: > > > 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] > > --- > 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]
