Vincent Massol wrote:
> Hi Nicola,
>
> [snip]
>
> Trying to have each plugin independent one of another is a nice goal.
> But difficult to achieve without lots of build code duplication. Just
> check the Ant dependency graphs
> (http://www.teria.com/~koseki/vizant/examples.html), you'll see that
> there are dependencies between functional build units. If you normalize
> them, you duplicate lots of code.
I don't normalize them. I simply don't rely on them.
> Thus, we need a way to tell the master build that before we run our new
> plugin, it has to run such and such targets/goals from such other
> plugin. Yes, I know, we introduce plugin dependency but just as long as
> our new plugin only relies on core plugins there is no problem (same
> issue as Ant build files relying on core ant tasks vs optional ones - we
> just abstract one level higher, plugins instead of tasks).
I go one level higher again.
I define features, which are collections of tasks that attain a logical
goal (compile, test, etc...)
> In addition, let's say I add a Test Coverage plugin. As a user, I may or
> may not want it to be called when I run the "site" target to generate
> the web site. Thus I need a way to tell this to Maven.
>
> Maven provides a default wiring of targets but we need to let the user
> the ability to add either his own build code before/after or change the
> order of targets (not sure we have that yet in Maven, do we Jason/Bob ?
> I mean can a user change the default sequence order of targets ?).
>
> I don't see what is wrong with that ?
Not wrong, just unnededly convoluted.
Look, you overload the concept of target by giving it a logical goal:
build, site, jar, etc.
Then give it a default implementation, a default dependency and pre and
post additional stuff.
What we do is instead to define features (your common goals), define the
dependency between them, but don't define either the default
implementation nor pre or post stuff.
We just put a sequence of plugin goals there.
It's just a different way of doing the same thing; we reckon it's easier
to maintain, understand and create.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
