As for the current build planner, I was going to fix it for forked executions from reports, until we started discussing the refactoring of the plugin manager. As for the config/binding for plugins invoked by plugins, IMO it would be part of the master plugin in some form. Admittedly, this form of cascaded invocation might be less flexible than configuring each individually in the POM (in a flat build structure), but maintaining maximum flexibility may not be that important...particularly when you have a narrowed subset of behavior that you need from the cascaded plugin invocation.
I'm not saying that we should do this instead of plugin inheritance...at times, inheritance definitely makes more sense. However, to me it would make more sense to open this up as a possibility instead of expanding @execute any further. This gives better control over "decorating" the forked execution, and allows you to orchestrate more than a single forked execution, which is sometimes very desirable. -john On 5/13/07, Brett Porter <[EMAIL PROTECTED]> wrote:
On 13/05/2007, at 8:05 PM, John Casey wrote: > I'd like to see what people think about cleaning up the plugin > manager for > use as a separate API. +1 - we keep seeing the same concept popping up all over. Not sure if it's needed for the first alpha, or even 2.1 itself though. > 1. remove the site plugin from the maven lifecycle. I was getting the indication that making the plugin execution environment independent (Something on Jason's list, I think I forgot it earlier) would achieve this anyway - but I may be wrong. > > I was a little surprised to see the way report mojos are handled > in the > old lifecycle executor (now the build planner stuff, though > reporting is a Yep, total hack around the lack of capability in the plugin manager to deal with the use case. > little broken for reports that fork their own executions). So we have to do something then, regardless? > 2. create compound plugins. > > In some cases (like the assembly or release plugins), mojos get to be > pretty complex and hard to manage. In many cases, these plugins > could reuse > the behavior of other existing plugins, if those plugins were > designed for > reuse. In cases where the plugins just need to replicate build-time > actions > of other plugins, it may make more sense to allow them to invoke > those mojos > or lifecycle phases directly. This goes beyond @execute, since > logic can be > introduced in between executions, and executions could become > conditional. I'm not sure getting a handle on the plugin manager is the right approach to this, but I'd need to look it in more detail. I'm not sure where the configuration / binding comes from in this instance. - Brett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- John Casey --- Maven Developer (http://maven.apache.org) --- Blog: http://www.ejlife.net/blogs/buildchimp
