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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 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
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
I've already removed it from the default lifecycle mapping in 3.x.
On 21-May-09, at 2:52 PM, Benjamin Bentmann wrote:
Hi,
Remove invocation of maven-plugin-plugin:updatePluginRegistry from
default lifecycle bindings
---
+1
On Thu, May 21, 2009 at 10:51 PM, John Casey wrote:
> Sounds good to me. If we remove it from the default lifecycle mapping,
> people could always add it back in...at least then they'd definitely know if
> they need it. :-)
>
> Having said that, I'd be *very* surprised if anyone is actually u
2009/5/20 Mark Hobson :
> Just noticed this thread after posting a proposed solution to mojo-dev:
> http://markmail.org/message/qnipbser4hktewvq
I've fixed this in mojo-parent, do you want me to also apply the fix
to maven-parent and deploy a new snapshot?
Mark
--
24 matches
Mail list logo