> -----Original Message-----
> From: Michal Maczka [mailto:[EMAIL PROTECTED]
> Sent: 11 November 2003 11:16
> To: Maven Developers List
> Subject: Re: cvs commit:
maven-plugins/multichanges/src/plugin-resources
> releases.jsl
> 
> Vincent Massol wrote:
> 
> >dIon,
> >
> >I don't quite agree. Each of these plugins are separate. Sharing the
> >same properties ties them together. I would agree, provided the
> >multiproject plugin provides some useful infrastructure for all
plugins
> >dealing with several projects. In which case the other plugins would
> >"extend" it and it would make sense to share properties. Tying them
> >together just to share some properties does not seem enough to me to
> >justify the tie.
> >
> >Ideas?
> >
> >
> >
> >
> I agree with dIon here.

Please see the proposal for a multireport plugin (or whatever name we
wish to call it). That would solve part of the issue.

> 
> We have alredy have a set of properties which are shared among plugins
> and even such properties which don't belong
> to any plugin (like ${maven.build.dest}}.
> 
> I see that  you are not happy about the fact that multiproject plugin
is
> in some way  favourized.
> 
> Then we can imagine to have( as for this just compilcates things for
end
> user):
> 
> maven.reactor.basedir=${basedir}
> maven.reactor.includes=*/project.xml
> maven.reactor.excludes=**/target/**/project.xml,project.xml
> maven.reactor.ignoreFailures=false
> 
> 
> (and then default setting per plugin)
> 
> maven.multiproject.basedir=${maven.reactor.basedir}
> maven.multiproject.includes=${maven.reactor.includes}
> maven.multiproject.excludes=${maven.reactor.excludes}
> maven.multiproject.ignoreFailures={maven.reactor.ignoreFailures}
> 
> 
> maven.multichanges.basedir=${maven.reactor.basedir}
> maven.multichanges.includes=${maven.reactor.includes}
> maven.multichanges.excludes=${maven.reactor.excludes}
> 
> maven.multichanges.ignoreFailures=${maven.reactor.ignoreFailures}
> 
> 
> So no plugin is favourized.
> 
> The fundamental question here is: shall we use properties which belong
> to no plugin and what technical problems it can cause.
> If this should be recommended or forbbiden pratice.
> 
> I personally have noting against using  properties of multiproject
> plugin in other plugins.
> 
> [completly off topic]We can even imagine to have plugins of the
> multiproject plugin:
> so multiproject is a plugin which runs reactor in favour of its
plugins
> and those plugins can be e.g plugged into maven reporting API.

This is what already exists with the site plugin. And it is what I am
proposing in my other email. However there are 2 features we're looking
for:

1- Ability to simply execute the same goal over several plugins
2- Report aggregator

The multiproject could stay the way it is and provide feature 1. The
multireport plugin could do 2. 

> Plugins of multiproject need not even be plugins in maven sense. They
> can be scripts or java classes
>  In case of reactor-powered plugins this can speed up many things in
> significant way.

Yes, that's what I imagine with the multireport stuff.

-Vincent


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to