Should the multiproject plugin strategy be changed?

[Vincent Massol <vm...@pivolis.com>]

Hi,

I've taken the time review the multiproject plugin in order to assess
whether the dashboard plugin should rely on it.

The multiproject contains goals related to building stuff depending on
several projects. It initially started with the multiproject:site stuff
and then several other goals were added.

My feeling is that the multiproject has outgrown it's original usage (or
it will soon). If we follow the initial multiproject logic we should add
the dashboard plugin code + the multichanges code + all the others
plugins I have in mind (quite a few :-)) to the multiproject plugin.
However, I think it will make the plugin too big and not focused enough.
This was the reason I've created specific projects for dashboard and
multichanges.

Now of course, the dashboard and multichanges projects can call the
multiproject:goal goal but it won't buy us much in term of reuse.

The real question is whether we want to have a special strategy for all
plugins working on several plugins. Like putting them in some special
category/directory/etc?

I'd personally prefer the following approach: group plugins by business
functionality instead of by technical feature. For example, I would very
much prefer to see the multiproject:site goal be integrated in the site
plugin as it is related to build sites. The multichanges plugin code
would go in the release plugin (it is badly name as its goal is to
generate a release dashboard), etc.

Said in another way, I don't think the current multiproject plugin
design is scalable. And I think it has reached its limit.

Waddyathink?

Thanks
-Vincent


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org