Re: executions, phases and multiple goals

2009-05-22 Thread Jason van Zyl
On 22-May-09, at 8:44 PM, Brian Fox wrote: I feel like this is pretty low on the list of problems to be solved, but if the allowed phases can be a wildcard, then I guess I'm neutral on the idea. I think things like pom versioning are far more pressing. Sure, I agree. It was brought up so

Re: executions, phases and multiple goals

2009-05-22 Thread Brian Fox
I feel like this is pretty low on the list of problems to be solved, but if the allowed phases can be a wildcard, then I guess I'm neutral on the idea. I think things like pom versioning are far more pressing. On Fri, May 22, 2009 at 8:10 PM, Jason van Zyl wrote: > > On 22-May-09, at 4:36 PM, Jo

Re: executions, phases and multiple goals

2009-05-22 Thread Jason van Zyl
On 22-May-09, at 4:36 PM, John Casey wrote: Jason van Zyl wrote: On 22-May-09, at 3:23 PM, Benjamin Bentmann wrote: Jason van Zyl wrote: Or if the assembly plugin is truly a utility player then have no suggested binding. [...] I think the phase as a suggestion is probably just confusin

Re: executions, phases and multiple goals

2009-05-22 Thread John Casey
Jason van Zyl wrote: On 22-May-09, at 3:23 PM, Benjamin Bentmann wrote: Jason van Zyl wrote: Or if the assembly plugin is truly a utility player then have no suggested binding. [...] I think the phase as a suggestion is probably just confusing. I don't think providing defaults like a de

Re: executions, phases and multiple goals

2009-05-22 Thread Benjamin Bentmann
Stephen Connolly wrote: I would be in favour of replacing @phase with @allowedPhases and @defaultPhase Right, the next step to go is using Java annotations instead of taglets so hyphens would be problematic. Benjamin - To

Re: executions, phases and multiple goals

2009-05-22 Thread Brian Fox
On Fri, May 22, 2009 at 4:23 PM, Benjamin Bentmann < benjamin.bentm...@udo.edu> wrote: > Jason van Zyl schrieb: > > We could even do something like @phase package,install if you truly think >> something belongs and has been tested to run in those phases. >> > > Nice idea, but maybe a dedicated ne

Re: executions, phases and multiple goals

2009-05-22 Thread Stephen Connolly
I would be in favour of replacing @phase with @allowedPhases and @defaultPhase Sent from my [rhymes with myPod] ;-) On 22 May 2009, at 20:52, Jason van Zyl wrote: On 22-May-09, at 3:23 PM, Benjamin Bentmann wrote: Jason van Zyl wrote: Or if the assembly plugin is truly a utility player

Re: executions, phases and multiple goals

2009-05-22 Thread Benjamin Bentmann
Jason van Zyl schrieb: We could even do something like @phase package,install if you truly think something belongs and has been tested to run in those phases. Nice idea, but maybe a dedicated new annotation instead, e.g. @phase package @allowed-phases package,install That would keep the

Re: executions, phases and multiple goals

2009-05-22 Thread Brian Fox
I don't think we should take away the ability of a user to override a phase in a plugin. For things like the dependency plugin, I specify a sensible default, but there are many valid cases to run that plugin in other phases, I do it myself. I tend to think the current functionality is working as in

Re: executions, phases and multiple goals

2009-05-22 Thread Jason van Zyl
On 22-May-09, at 3:23 PM, Benjamin Bentmann wrote: Jason van Zyl wrote: Or if the assembly plugin is truly a utility player then have no suggested binding. [...] I think the phase as a suggestion is probably just confusing. I don't think providing defaults like a default phase binding in

Re: executions, phases and multiple goals

2009-05-22 Thread Benjamin Bentmann
Jason van Zyl wrote: Or if the assembly plugin is truly a utility player then have no suggested binding. [...] I think the phase as a suggestion is probably just confusing. I don't think providing defaults like a default phase binding in this case is confusing. It's just convention over conf

Re: executions, phases and multiple goals

2009-05-22 Thread Jason van Zyl
On 22-May-09, at 1:39 PM, John Casey wrote: Jason van Zyl wrote: On 22-May-09, at 11:29 AM, Stephen Connolly wrote: 2009/5/22 Jason van Zyl On 22-May-09, at 10:46 AM, Stephen Connolly wrote: Then both goals are bound to the integration-test phase, as I would expect I think 2.x is

Re: executions, phases and multiple goals

2009-05-22 Thread John Casey
Jason van Zyl wrote: On 22-May-09, at 11:29 AM, Stephen Connolly wrote: 2009/5/22 Jason van Zyl On 22-May-09, at 10:46 AM, Stephen Connolly wrote: Then both goals are bound to the integration-test phase, as I would expect I think 2.x is a little lax. It should blow up and tell you

Re: executions, phases and multiple goals

2009-05-22 Thread John Casey
This is a feature. If no phase definition is provided for an execution, then each mojo is bound to the phase declared in the @phase annotation, if one is declared. Stephen Connolly wrote: OK, I just noticed this... If I have two mojo's annotated with different phases, i.e. /** * @goal integ

Re: executions, phases and multiple goals

2009-05-22 Thread Stephen Connolly
2009/5/22 Jason van Zyl > > On 22-May-09, at 11:29 AM, Stephen Connolly wrote: > > 2009/5/22 Jason van Zyl >> >> >>> On 22-May-09, at 10:46 AM, Stephen Connolly wrote: >>> >>> >>> Then both goals are bound to the integration-test phase, as I would expect I think 2.x is a l

Re: executions, phases and multiple goals

2009-05-22 Thread Jason van Zyl
On 22-May-09, at 11:29 AM, Stephen Connolly wrote: 2009/5/22 Jason van Zyl On 22-May-09, at 10:46 AM, Stephen Connolly wrote: Then both goals are bound to the integration-test phase, as I would expect I think 2.x is a little lax. It should blow up and tell you that you're trying to

Re: executions, phases and multiple goals

2009-05-22 Thread Stephen Connolly
2009/5/22 Jason van Zyl > > On 22-May-09, at 10:46 AM, Stephen Connolly wrote: > > >> Then both goals are bound to the integration-test phase, as I would expect >> >> > I think 2.x is a little lax. It should blow up and tell you that you're > trying to wire the mojo to a phase not specified in th

Re: executions, phases and multiple goals

2009-05-22 Thread Stephen Connolly
2009/5/22 Jason van Zyl > > >> It'd be nice if it was a feature... but I suspect it is a bug... >> >> > The mojos are binding to phase declared in the annotations. Why do you > think this would be a bug? > Because I have not seen it documented anywhere else before... so before I go running off t

Re: executions, phases and multiple goals

2009-05-22 Thread Jason van Zyl
On 22-May-09, at 10:46 AM, Stephen Connolly wrote: OK, I just noticed this... If I have two mojo's annotated with different phases, i.e. /** * @goal integration-test * @requiresProject true * @requiresDependencyResolution test * @phase integration-test */ public class FailsafeMojo extends

Re: executions, phases and multiple goals

2009-05-22 Thread Stephen Connolly
2009/5/22 Stephen Connolly > OK, I just noticed this... > > If I have two mojo's annotated with different phases, i.e. > > /** > * @goal integration-test > * @requiresProject true > * @requiresDependencyResolution test > * @phase integration-test > */ > public class FailsafeMojo > extend

executions, phases and multiple goals

2009-05-22 Thread Stephen Connolly
OK, I just noticed this... If I have two mojo's annotated with different phases, i.e. /** * @goal integration-test * @requiresProject true * @requiresDependencyResolution test * @phase integration-test */ public class FailsafeMojo extends AbstractMojo { ... } and /** * @goal verify