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
