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
