yes, I see what your talking about.. And I think your might be onto something with your BuildPlanModifier bit...It seems to me that plugins have perhaps grown a bit too...powerful in terms of how they can effect the build.
I wonder if it might be a good time while your looking into all of this to take a look at the totality of plugins out there and maybe slice this problem up a bit. There are a ton of plugins that have a really clear separation of concerns in term of the overall build. But it gets murky really quick. Source generation plugins for example, they do one thing and one thing well, they generate a mess of source and then tell maven that it needs to consider these things when building from that point on...basically configuring something like that compiler plugin on the fly during plugin execution...or sometimes skipping execution if they already have run. It might be prohibitively a pain in the arse to do, but perhaps it would nice to flesh out some additional specific Mojo++ interfaces that your build. Source generation plugins all share many facets... * they generate source someplace * they conditionally run or not based on source * they influence another phase of the lifecycle specifically (like the compiling and test compiling) I could easily see another case where X different mojo's can be used to fork off running process in one phase and be shut down in another (testing webservices in your build by deploying into a container, running selenium against it and then shutting container down). The normal Mojo interface is very simple and lets you do a massive amount of different things...would it make sense to expand on that a bit while your at it with this build planning working? it might net you some more information and make the build planning more informative and declarative. jesse On Jan 31, 2008 9:52 AM, John Casey <[EMAIL PROTECTED]> wrote: > You know, I've been thinking about that bit, too...turning mojos off, > replacing them, etc, I mean. What I'm currently thinking is that a > build extension that carried its own configuration might be a good > alternative, though I'm not sure how well that would scale. The idea > is to introduce a hook for modifying the build plan before the > lifecycle executor, session, or execution-result can get their hands > on it. The modifier hook would basically be a lookup for all > extensions that implement BuildPlanModifier in the current project's > lookup realm, then just iterating through them...the result would be > passed back to Maven for execution, reference, etc. > > I think we're starting to stretch the constraints on what a normal > plugin (i.e. something that functions during the building of a > project) is supposed to do. The idea of a build-plan modifier is > almost a meta-plugin, in that it modifies the system of plugins that > execute the build, and it dovetails pretty neatly with some other > similar hooks I could imagine that are related to Brian's first and > third comments on the Deterministic Lifecycle Planning page, citing > the need to have "pre-execution" and "post-execution" phases, where > things can modify dependencies, cleanup after a build (think finally > clause, at least that's what it reminds me of), etc. This is really > bigger than your normal plugin, in that it modifies the system > itself, not the target project. > > However, to do this, we would really need to talk about providing a > configuration section in the build extensions section of the POM, to > allow the ordering and options given to these modifiers to be stated > plainly alongside the normal plugin configuration (getting back to > that determinism goal). > > Does this all make sense? > > -john > > On Jan 30, 2008, at 2:58 PM, Jesse McConnell wrote: > > > 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] > > --- > 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]
