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
2009/5/22 Stephen Connolly stephen.alan.conno...@gmail.com
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
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
2009/5/22 Jason van Zyl jvan...@sonatype.com
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
2009/5/22 Jason van Zyl jvan...@sonatype.com
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
2009/5/22 Jason van Zyl jvan...@sonatype.com
On 22-May-09, at 11:29 AM, Stephen Connolly wrote:
2009/5/22 Jason van Zyl jvan...@sonatype.com
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
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
Jason van Zyl wrote:
On 22-May-09, at 11:29 AM, Stephen Connolly wrote:
2009/5/22 Jason van Zyl jvan...@sonatype.com
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
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 jvan...@sonatype.com
On 22-May-09, at 10:46 AM, Stephen Connolly wrote:
Then both goals are bound to the integration-test phase, as I
would
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
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
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
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
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 jvan...@sonatype.com wrote:
On 22-May-09, at 3:23 PM, Benjamin Bentmann wrote:
Jason van Zyl wrote:
Or if the assembly plugin is
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 new
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
-
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
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
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 jvan...@sonatype.com wrote:
On
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
20 matches
Mail list logo
