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]
