That's the existing process, where the next mojo to be executed is
discovered based on the metadata of the current one...if the current
mojo requires a fork, the mojos to be included in that fork are
calculated just before the forking mojo is executed. As you go
through the build, executing mojos as you find them, you can easily
come across a plugin with nonsensical or somehow invalid or
inaccessible forking information. A plugin may be unresolvable, the
mojo referenced in a fork may not exist in the current plugin, the
lifecycle phase itself may not exist, etc, etc. While some of this
can definitely be checked when the plugin is built, that's not a
perfect solution. It's better to do the discovery of the complete
lifecycle (at least, as far as you can reasonably do so) before you
execute anything, to minimize the risk of exiting the build in a
partial state because of bad plugin metadata.
It also gives us the ability to tell the user up front what Maven
will do in the build, optionally without actually doing it at all.
-john
On Feb 11, 2008, at 5:03 PM, Rahul Thakur wrote:
Hi John,
That looks very interesting!
BTW, what is 'Just-in-time lifecycle discovery and configuration'?
Rahul
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [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
