You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Stephen Connolly <st...@gmail.com> on 2009/05/22 16:46:23 UTC
executions, phases and multiple goals
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
* @requiresProject true
* @requiresDependencyResolution test
* @phase verify
*/
public class VerifyMojo
extends AbstractMojo
{
...
}
If I add to my pom.xml
<project>
..
<build>
..
<plugins>
...
<plugin>
<groupId>....</groupId>
<artifactId>....</artifactId>
<version>...</version>
...
* <executions>
<execution>
<goals>
<goal>integration-test</goal>
<goal>verify</goal>
</goals>
</execution>
</executions>
* </plugin>
...
</plugins>
...
</build>
</project>
Then the integration-test goal is bound to the integration-test phase and
the verify goal is bound to the verify phase.
My question is this... is this a feature or a bug?
It'd be nice if it was a feature... but I suspect it is a bug...
Just to confirm for everyone...
If I add
<project>
..
<build>
..
<plugins>
...
<plugin>
<groupId>....</groupId>
<artifactId>....</artifactId>
<version>...</version>
...
* <executions>
<execution>
<phase>integration-test</phase>
<goals>
<goal>integration-test</goal>
<goal>verify</goal>
</goals>
</execution>
</executions>
* </plugin>
...
</plugins>
...
</build>
</project>
Then both goals are bound to the integration-test phase, as I would expect
-Stephen
Re: executions, phases and multiple goals
Posted by John Casey <jd...@commonjava.org>.
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 integration-test
> * @requiresProject true
> * @requiresDependencyResolution test
> * @phase integration-test
> */
> public class FailsafeMojo
> extends AbstractMojo
> {
> ...
> }
>
> and
>
> /**
> * @goal verify
> * @requiresProject true
> * @requiresDependencyResolution test
> * @phase verify
> */
> public class VerifyMojo
> extends AbstractMojo
> {
> ...
> }
>
>
> If I add to my pom.xml
>
> <project>
> ..
> <build>
> ..
> <plugins>
> ...
> <plugin>
> <groupId>....</groupId>
> <artifactId>....</artifactId>
> <version>...</version>
> ...
> * <executions>
> <execution>
> <goals>
> <goal>integration-test</goal>
> <goal>verify</goal>
> </goals>
> </execution>
> </executions>
> * </plugin>
> ...
> </plugins>
> ...
> </build>
> </project>
>
> Then the integration-test goal is bound to the integration-test phase and
> the verify goal is bound to the verify phase.
>
> My question is this... is this a feature or a bug?
>
> It'd be nice if it was a feature... but I suspect it is a bug...
>
> Just to confirm for everyone...
>
> If I add
>
> <project>
> ..
> <build>
> ..
> <plugins>
> ...
> <plugin>
> <groupId>....</groupId>
> <artifactId>....</artifactId>
> <version>...</version>
> ...
> * <executions>
> <execution>
> <phase>integration-test</phase>
> <goals>
> <goal>integration-test</goal>
> <goal>verify</goal>
> </goals>
> </execution>
> </executions>
> * </plugin>
> ...
> </plugins>
> ...
> </build>
> </project>
>
> Then both goals are bound to the integration-test phase, as I would expect
>
> -Stephen
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: executions, phases and multiple goals
Posted by Benjamin Bentmann <be...@udo.edu>.
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 unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: executions, phases and multiple goals
Posted by Stephen Connolly <st...@gmail.com>.
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 <jv...@sonatype.com> 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 default phase binding in
>> this case is confusing. It's just convention over configuration,
>> isn't it?
>
> Changing a source directory does not change the behavior of a build.
> The convention for something designed to be truly pluggable.
> Changing the phase the assembly plugin alters the way it works.
> There is the weirdo magic, as a case in point, where depending on
> what phase you are in you might get a directory or an archive as a
> resolved artifact. Then you're starting to look for files or
> directories in your plugin ... so I don't think this is a case of
> convention over configuration here. I think a mojo is either
> designed to work doing a single thing in a single phase of the
> lifecycle, or it's a utility player. Assigning a "default" phase
> only to have it be changed by a user likely means the mojo has not
> been tested in this case and will more likely then not cause someone
> confusion or just plain not work. We could even do something like
> @phase package,install if you truly think something belongs and has
> been tested to run in those phases.
>
>> The default value saves one from typing and also provides a hint
>> (not a restriction) about the major (but not the one and only)
>> usage of a goal.
>>
>> Hoping that we will leave some decisions to the user, not the tool...
>>
>
> The decisions that can be made by the user have to be options that
> were tested by the developers. If the developer was truly
> responsible for writing a mojo and was somehow made to incur the
> cost of support then I'm willing to bet that they would limit how
> that mojo was used. I think it would be fine to allow a developer to
> specify all the phases the plugin is known to run in and then the
> user works within the known set of viable conditions. I think we
> need to be very realistic about what can be supported and I think
> this ultimately benefits everyone. If a system lets you do something
> then one should reasonably expect it to work. There are already
> complete free-for-alls for people to use and I think we have to
> consider allowing less but works exactly as advertised.
>
>>
>> Benjamin
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/SonatypeNexus
> http://twitter.com/SonatypeM2E
> ----------------------------------------------------------
>
> Our achievements speak for themselves. What we have to keep track
> of are our failures, discouragements and doubts. We tend to forget
> the past difficulties, the many false starts, and the painful
> groping. We see our past achievements as the end result of a
> clean forward thrust, and our present difficulties as
> signs of decline and decay.
>
> -- Eric Hoffer, Reflections on the Human Condition
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: executions, phases and multiple goals
Posted by Brian Fox <br...@infinity.nu>.
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 intended, but I
personally wouldn't do it that way. I like to see my executions clearly
lined up with the phase and goal and config. I can count on one hand the
number of times I've invoked multiple goals from a single plugin at the same
time.
Having ITs to guarantee this functionality remains is needed if they don't
exist already (i'd bet they don't)
On Fri, May 22, 2009 at 3:52 PM, Jason van Zyl <jv...@sonatype.com> 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 default phase binding in this case
>> is confusing. It's just convention over configuration, isn't it?
>>
>
> Changing a source directory does not change the behavior of a build. The
> convention for something designed to be truly pluggable. Changing the phase
> the assembly plugin alters the way it works. There is the weirdo magic, as a
> case in point, where depending on what phase you are in you might get a
> directory or an archive as a resolved artifact. Then you're starting to look
> for files or directories in your plugin ... so I don't think this is a case
> of convention over configuration here. I think a mojo is either designed to
> work doing a single thing in a single phase of the lifecycle, or it's a
> utility player. Assigning a "default" phase only to have it be changed by a
> user likely means the mojo has not been tested in this case and will more
> likely then not cause someone confusion or just plain not work. We could
> even do something like @phase package,install if you truly think something
> belongs and has been tested to run in those phases.
>
> The default value saves one from typing and also provides a hint (not a
>> restriction) about the major (but not the one and only) usage of a goal.
>>
>> Hoping that we will leave some decisions to the user, not the tool...
>>
>>
> The decisions that can be made by the user have to be options that were
> tested by the developers. If the developer was truly responsible for writing
> a mojo and was somehow made to incur the cost of support then I'm willing to
> bet that they would limit how that mojo was used. I think it would be fine
> to allow a developer to specify all the phases the plugin is known to run in
> and then the user works within the known set of viable conditions. I think
> we need to be very realistic about what can be supported and I think this
> ultimately benefits everyone. If a system lets you do something then one
> should reasonably expect it to work. There are already complete
> free-for-alls for people to use and I think we have to consider allowing
> less but works exactly as advertised.
>
>
>> Benjamin
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/SonatypeNexus
> http://twitter.com/SonatypeM2E
> ----------------------------------------------------------
>
> Our achievements speak for themselves. What we have to keep track
> of are our failures, discouragements and doubts. We tend to forget
> the past difficulties, the many false starts, and the painful
> groping. We see our past achievements as the end result of a
> clean forward thrust, and our present difficulties as
> signs of decline and decay.
>
> -- Eric Hoffer, Reflections on the Human Condition
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: executions, phases and multiple goals
Posted by Brian Fox <br...@infinity.nu>.
On Fri, May 22, 2009 at 4:23 PM, Benjamin Bentmann <
benjamin.bentmann@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 annotation instead, e.g.
>
> @phase package
> @allowed-phases package,install
>
>
Too much big brother and it reduces the usability of plugins. A plugin
should be self contained and work in all cases.
>
>
>
>
> Benjamin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: executions, phases and multiple goals
Posted by Benjamin Bentmann <be...@udo.edu>.
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 syntax of @phase compatible with 2.x (especially in
the plugin descriptor) and indicates/suggests the default binding, yet
allows to limit the bindings to the supported ones while not being
restricted to merely one phase, eliminating the need for developers to
create almost empty subclasses of a mojo just to declare another phase
binding. If users can present valid use cases for other phases, the mojo
developer could review them and consider their support, possibly
extending the @allowed-phases in a future release. OK, that sounds fair
to me.
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: executions, phases and multiple goals
Posted by Jason van Zyl <jv...@sonatype.com>.
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 commented.
> On Fri, May 22, 2009 at 8:10 PM, Jason van Zyl
> <jv...@sonatype.com> wrote:
>
>>
>> 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
>>>>>> confusing.
>>>>>>
>>>>>
>>>>> I don't think providing defaults like a default phase binding in
>>>>> this
>>>>> case is confusing. It's just convention over configuration,
>>>>> isn't it?
>>>>>
>>>> Changing a source directory does not change the behavior of a
>>>> build. The
>>>> convention for something designed to be truly pluggable. Changing
>>>> the phase
>>>> the assembly plugin alters the way it works. There is the weirdo
>>>> magic, as a
>>>> case in point, where depending on what phase you are in you might
>>>> get a
>>>> directory or an archive as a resolved artifact. Then you're
>>>> starting to look
>>>> for files or directories in your plugin ... so I don't think this
>>>> is a case
>>>> of convention over configuration here. I think a mojo is either
>>>> designed to
>>>> work doing a single thing in a single phase of the lifecycle, or
>>>> it's a
>>>> utility player. Assigning a "default" phase only to have it be
>>>> changed by a
>>>> user likely means the mojo has not been tested in this case and
>>>> will more
>>>> likely then not cause someone confusion or just plain not work.
>>>> We could
>>>> even do something like @phase package,install if you truly think
>>>> something
>>>> belongs and has been tested to run in those phases.
>>>>
>>>
>>> I don't think it's more intuitive to have this proliferation of
>>> new mojos,
>>> simply to handle explicitly all the potential places where it
>>> might be
>>> appropriate to use a particular piece of build logic. As it is in
>>> the
>>> assembly plugin, we have five or more mojos (owing to legacy
>>> issues) that do
>>> 99% the same thing, but they're named differently to handle the 1%
>>> difference in logic. Actually, the 1% difference is now accounted
>>> for almost
>>> completely in the shared code, so the 1% difference is a legacy
>>> notion as
>>> well. Now, in your approach, I'll have to create at least several
>>> more mojos
>>> to handle cases where people want to use the assembly plugin in
>>> different
>>> phases. I simply cannot remove the '@phase' annotation, because in
>>> 80% of
>>> cases the user wants to use a dependencySet which requires
>>> dependency
>>> resolution, so providing '@phase package' eliminates configuration
>>> (by
>>> providing a convention) for 80% of use cases.
>>>
>>
>> You don't need a proliferation of mojos, you would specify what
>> phases you
>> know to work. If you can account for a single mojo to work in
>> multiple
>> phases and cover all the different logic then you have a single
>> mojo. My
>> point is state what you do well, if the rest is unsure then Maven
>> should
>> stop. I'm not talking about what Maven does now, I'm talking about
>> how to
>> ideally stop users from stepping into a mistake. I like the idea of a
>> default phase and allowed phases.
>>
>>
>>> I think it's a mistake to enforce your assumptions about the
>>> quality of
>>> tests and/or code in plugins. It would truly be a case of coding
>>> for the
>>> lowest common denominator, and imposing a serious penalty on
>>> plugins that
>>> have legitimate reasons for leaving the default + configuration in
>>> place.
>>>
>>
>> Coding for the lowest common denominator? How do you see a
>> developer of a
>> mojo who clearly states where the mojo runs because they've tested
>> it and
>> know this to be the lowest common denominator?
>>
>>
>>> The default value saves one from typing and also provides a hint
>>> (not a
>>>>> restriction) about the major (but not the one and only) usage of
>>>>> a goal.
>>>>>
>>>>> Hoping that we will leave some decisions to the user, not the
>>>>> tool...
>>>>>
>>>>> The decisions that can be made by the user have to be options
>>>>> that were
>>>> tested by the developers. If the developer was truly responsible
>>>> for writing
>>>> a mojo and was somehow made to incur the cost of support then I'm
>>>> willing to
>>>> bet that they would limit how that mojo was used. I think it
>>>> would be fine
>>>> to allow a developer to specify all the phases the plugin is
>>>> known to run in
>>>> and then the user works within the known set of viable
>>>> conditions. I think
>>>> we need to be very realistic about what can be supported and I
>>>> think this
>>>> ultimately benefits everyone. If a system lets you do something
>>>> then one
>>>> should reasonably expect it to work. There are already complete
>>>> free-for-alls for people to use and I think we have to consider
>>>> allowing
>>>> less but works exactly as advertised.
>>>>
>>>
>>> I'm all for this sort of documentation, telling users where a
>>> particular
>>> plugin is safe to run. But let's not throw the baby out with the
>>> bathwater
>>> here. There are cases where plugins could be used almost anywhere
>>> in the
>>> build process (especially if they're not producing something
>>> involved in the
>>> "main line" of compiling/testing/etc. the actual source code).
>>>
>>
>> That's if that's the case then they would have no default phase and
>> be
>> allowed everywhere. If that's the case for the plugin the contract
>> in the
>> mojo says that. Plugins that are found to have worthless contracts
>> will soon
>> not be used by people.
>>
>> And frankly, there are also cases where some builds get pretty
>> crowded in
>>> certain lifecycle phases, and it's helpful to get a little
>>> creative with
>>> phase bindings in cases where something has to happen "at some
>>> point" before
>>> something else, but it doesn't necessarily matter when.
>>>
>>
>> I think this is indicative of other problems. If there is no clear
>> place to
>> put something, or moreover no clear way to order within a phase.
>> Again I'm
>> not talking about what we're saddled with now in 2.x but what the
>> system
>> could and should be like.
>>
>>
>>> Of course this is a little vague, but that's the point; we cannot
>>> possibly
>>> account for every single concrete build use case in the entire
>>> world.
>>>
>>
>> We don't have to, but mojos can certainly have tighter contracts
>> and if
>> something is not meant for a particular lifecycle that will also be
>> more
>> clear.
>>
>> We don't have the infrastructure to document them, nor do we want to
>>> engage in the endless rounds of releases required to support that
>>> extra,
>>> marginal use case that walks in. We need to provide a tool that
>>> operates in
>>> a declarative way at build time, but still offers users just
>>> enough wiggle
>>> room to fit Maven responsibly around their own needs. Is this a
>>> balancing
>>> act? Of course it is, and not all of the resulting builds will
>>> look like
>>> elegant masterpieces of design. But the alternative is to tell
>>> those users,
>>> "Sorry, come back later when we release a new version that
>>> accommodates your
>>> use case." We have to try to do the right thing, but users
>>> absolutely must
>>> have enough rope to hang themselves, too.
>>>
>>> Tightening the usage of @phase will eliminate a lot of critical
>>> flexibility here.
>>>
>>
>> We'll agree to disagree then.
>>
>>
>>
>>> -john
>>>
>>>
>>>>> Benjamin
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>> Thanks,
>>>> Jason
>>>> ----------------------------------------------------------
>>>> Jason van Zyl
>>>> Founder, Apache Maven
>>>> http://twitter.com/jvanzyl
>>>> http://twitter.com/SonatypeNexus
>>>> http://twitter.com/SonatypeM2E
>>>> ----------------------------------------------------------
>>>> Our achievements speak for themselves. What we have to keep track
>>>> of are our failures, discouragements and doubts. We tend to forget
>>>> the past difficulties, the many false starts, and the painful
>>>> groping. We see our past achievements as the end result of a
>>>> clean forward thrust, and our present difficulties as
>>>> signs of decline and decay.
>>>> -- Eric Hoffer, Reflections on the Human Condition
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> http://twitter.com/SonatypeNexus
>> http://twitter.com/SonatypeM2E
>> ----------------------------------------------------------
>>
>> A man enjoys his work when he understands the whole and when he
>> is responsible for the quality of the whole
>>
>> -- Christopher Alexander, A Pattern Language
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
----------------------------------------------------------
A language that doesn’t affect the way you think about programming is
not worth knowing.
-— Alan Perlis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: executions, phases and multiple goals
Posted by Brian Fox <br...@infinity.nu>.
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 <jv...@sonatype.com> wrote:
>
> 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
>>>>> confusing.
>>>>>
>>>>
>>>> I don't think providing defaults like a default phase binding in this
>>>> case is confusing. It's just convention over configuration, isn't it?
>>>>
>>> Changing a source directory does not change the behavior of a build. The
>>> convention for something designed to be truly pluggable. Changing the phase
>>> the assembly plugin alters the way it works. There is the weirdo magic, as a
>>> case in point, where depending on what phase you are in you might get a
>>> directory or an archive as a resolved artifact. Then you're starting to look
>>> for files or directories in your plugin ... so I don't think this is a case
>>> of convention over configuration here. I think a mojo is either designed to
>>> work doing a single thing in a single phase of the lifecycle, or it's a
>>> utility player. Assigning a "default" phase only to have it be changed by a
>>> user likely means the mojo has not been tested in this case and will more
>>> likely then not cause someone confusion or just plain not work. We could
>>> even do something like @phase package,install if you truly think something
>>> belongs and has been tested to run in those phases.
>>>
>>
>> I don't think it's more intuitive to have this proliferation of new mojos,
>> simply to handle explicitly all the potential places where it might be
>> appropriate to use a particular piece of build logic. As it is in the
>> assembly plugin, we have five or more mojos (owing to legacy issues) that do
>> 99% the same thing, but they're named differently to handle the 1%
>> difference in logic. Actually, the 1% difference is now accounted for almost
>> completely in the shared code, so the 1% difference is a legacy notion as
>> well. Now, in your approach, I'll have to create at least several more mojos
>> to handle cases where people want to use the assembly plugin in different
>> phases. I simply cannot remove the '@phase' annotation, because in 80% of
>> cases the user wants to use a dependencySet which requires dependency
>> resolution, so providing '@phase package' eliminates configuration (by
>> providing a convention) for 80% of use cases.
>>
>
> You don't need a proliferation of mojos, you would specify what phases you
> know to work. If you can account for a single mojo to work in multiple
> phases and cover all the different logic then you have a single mojo. My
> point is state what you do well, if the rest is unsure then Maven should
> stop. I'm not talking about what Maven does now, I'm talking about how to
> ideally stop users from stepping into a mistake. I like the idea of a
> default phase and allowed phases.
>
>
>> I think it's a mistake to enforce your assumptions about the quality of
>> tests and/or code in plugins. It would truly be a case of coding for the
>> lowest common denominator, and imposing a serious penalty on plugins that
>> have legitimate reasons for leaving the default + configuration in place.
>>
>
> Coding for the lowest common denominator? How do you see a developer of a
> mojo who clearly states where the mojo runs because they've tested it and
> know this to be the lowest common denominator?
>
>
>> The default value saves one from typing and also provides a hint (not a
>>>> restriction) about the major (but not the one and only) usage of a goal.
>>>>
>>>> Hoping that we will leave some decisions to the user, not the tool...
>>>>
>>>> The decisions that can be made by the user have to be options that were
>>> tested by the developers. If the developer was truly responsible for writing
>>> a mojo and was somehow made to incur the cost of support then I'm willing to
>>> bet that they would limit how that mojo was used. I think it would be fine
>>> to allow a developer to specify all the phases the plugin is known to run in
>>> and then the user works within the known set of viable conditions. I think
>>> we need to be very realistic about what can be supported and I think this
>>> ultimately benefits everyone. If a system lets you do something then one
>>> should reasonably expect it to work. There are already complete
>>> free-for-alls for people to use and I think we have to consider allowing
>>> less but works exactly as advertised.
>>>
>>
>> I'm all for this sort of documentation, telling users where a particular
>> plugin is safe to run. But let's not throw the baby out with the bathwater
>> here. There are cases where plugins could be used almost anywhere in the
>> build process (especially if they're not producing something involved in the
>> "main line" of compiling/testing/etc. the actual source code).
>>
>
> That's if that's the case then they would have no default phase and be
> allowed everywhere. If that's the case for the plugin the contract in the
> mojo says that. Plugins that are found to have worthless contracts will soon
> not be used by people.
>
> And frankly, there are also cases where some builds get pretty crowded in
>> certain lifecycle phases, and it's helpful to get a little creative with
>> phase bindings in cases where something has to happen "at some point" before
>> something else, but it doesn't necessarily matter when.
>>
>
> I think this is indicative of other problems. If there is no clear place to
> put something, or moreover no clear way to order within a phase. Again I'm
> not talking about what we're saddled with now in 2.x but what the system
> could and should be like.
>
>
>> Of course this is a little vague, but that's the point; we cannot possibly
>> account for every single concrete build use case in the entire world.
>>
>
> We don't have to, but mojos can certainly have tighter contracts and if
> something is not meant for a particular lifecycle that will also be more
> clear.
>
> We don't have the infrastructure to document them, nor do we want to
>> engage in the endless rounds of releases required to support that extra,
>> marginal use case that walks in. We need to provide a tool that operates in
>> a declarative way at build time, but still offers users just enough wiggle
>> room to fit Maven responsibly around their own needs. Is this a balancing
>> act? Of course it is, and not all of the resulting builds will look like
>> elegant masterpieces of design. But the alternative is to tell those users,
>> "Sorry, come back later when we release a new version that accommodates your
>> use case." We have to try to do the right thing, but users absolutely must
>> have enough rope to hang themselves, too.
>>
>> Tightening the usage of @phase will eliminate a lot of critical
>> flexibility here.
>>
>
> We'll agree to disagree then.
>
>
>
>> -john
>>
>>
>>>> Benjamin
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>> Thanks,
>>> Jason
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder, Apache Maven
>>> http://twitter.com/jvanzyl
>>> http://twitter.com/SonatypeNexus
>>> http://twitter.com/SonatypeM2E
>>> ----------------------------------------------------------
>>> Our achievements speak for themselves. What we have to keep track
>>> of are our failures, discouragements and doubts. We tend to forget
>>> the past difficulties, the many false starts, and the painful
>>> groping. We see our past achievements as the end result of a
>>> clean forward thrust, and our present difficulties as
>>> signs of decline and decay.
>>> -- Eric Hoffer, Reflections on the Human Condition
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/SonatypeNexus
> http://twitter.com/SonatypeM2E
> ----------------------------------------------------------
>
> A man enjoys his work when he understands the whole and when he
> is responsible for the quality of the whole
>
> -- Christopher Alexander, A Pattern Language
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: executions, phases and multiple goals
Posted by Jason van Zyl <jv...@sonatype.com>.
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 confusing.
>>>
>>> I don't think providing defaults like a default phase binding in
>>> this case is confusing. It's just convention over configuration,
>>> isn't it?
>> Changing a source directory does not change the behavior of a
>> build. The convention for something designed to be truly pluggable.
>> Changing the phase the assembly plugin alters the way it works.
>> There is the weirdo magic, as a case in point, where depending on
>> what phase you are in you might get a directory or an archive as a
>> resolved artifact. Then you're starting to look for files or
>> directories in your plugin ... so I don't think this is a case of
>> convention over configuration here. I think a mojo is either
>> designed to work doing a single thing in a single phase of the
>> lifecycle, or it's a utility player. Assigning a "default" phase
>> only to have it be changed by a user likely means the mojo has not
>> been tested in this case and will more likely then not cause
>> someone confusion or just plain not work. We could even do
>> something like @phase package,install if you truly think something
>> belongs and has been tested to run in those phases.
>
> I don't think it's more intuitive to have this proliferation of new
> mojos, simply to handle explicitly all the potential places where it
> might be appropriate to use a particular piece of build logic. As it
> is in the assembly plugin, we have five or more mojos (owing to
> legacy issues) that do 99% the same thing, but they're named
> differently to handle the 1% difference in logic. Actually, the 1%
> difference is now accounted for almost completely in the shared
> code, so the 1% difference is a legacy notion as well. Now, in your
> approach, I'll have to create at least several more mojos to handle
> cases where people want to use the assembly plugin in different
> phases. I simply cannot remove the '@phase' annotation, because in
> 80% of cases the user wants to use a dependencySet which requires
> dependency resolution, so providing '@phase package' eliminates
> configuration (by providing a convention) for 80% of use cases.
You don't need a proliferation of mojos, you would specify what phases
you know to work. If you can account for a single mojo to work in
multiple phases and cover all the different logic then you have a
single mojo. My point is state what you do well, if the rest is unsure
then Maven should stop. I'm not talking about what Maven does now, I'm
talking about how to ideally stop users from stepping into a mistake.
I like the idea of a default phase and allowed phases.
>
> I think it's a mistake to enforce your assumptions about the quality
> of tests and/or code in plugins. It would truly be a case of coding
> for the lowest common denominator, and imposing a serious penalty on
> plugins that have legitimate reasons for leaving the default +
> configuration in place.
Coding for the lowest common denominator? How do you see a developer
of a mojo who clearly states where the mojo runs because they've
tested it and know this to be the lowest common denominator?
>
>>> The default value saves one from typing and also provides a hint
>>> (not a restriction) about the major (but not the one and only)
>>> usage of a goal.
>>>
>>> Hoping that we will leave some decisions to the user, not the
>>> tool...
>>>
>> The decisions that can be made by the user have to be options that
>> were tested by the developers. If the developer was truly
>> responsible for writing a mojo and was somehow made to incur the
>> cost of support then I'm willing to bet that they would limit how
>> that mojo was used. I think it would be fine to allow a developer
>> to specify all the phases the plugin is known to run in and then
>> the user works within the known set of viable conditions. I think
>> we need to be very realistic about what can be supported and I
>> think this ultimately benefits everyone. If a system lets you do
>> something then one should reasonably expect it to work. There are
>> already complete free-for-alls for people to use and I think we
>> have to consider allowing less but works exactly as advertised.
>
> I'm all for this sort of documentation, telling users where a
> particular plugin is safe to run. But let's not throw the baby out
> with the bathwater here. There are cases where plugins could be used
> almost anywhere in the build process (especially if they're not
> producing something involved in the "main line" of compiling/testing/
> etc. the actual source code).
That's if that's the case then they would have no default phase and be
allowed everywhere. If that's the case for the plugin the contract in
the mojo says that. Plugins that are found to have worthless contracts
will soon not be used by people.
> And frankly, there are also cases where some builds get pretty
> crowded in certain lifecycle phases, and it's helpful to get a
> little creative with phase bindings in cases where something has to
> happen "at some point" before something else, but it doesn't
> necessarily matter when.
I think this is indicative of other problems. If there is no clear
place to put something, or moreover no clear way to order within a
phase. Again I'm not talking about what we're saddled with now in 2.x
but what the system could and should be like.
>
> Of course this is a little vague, but that's the point; we cannot
> possibly account for every single concrete build use case in the
> entire world.
We don't have to, but mojos can certainly have tighter contracts and
if something is not meant for a particular lifecycle that will also be
more clear.
> We don't have the infrastructure to document them, nor do we want to
> engage in the endless rounds of releases required to support that
> extra, marginal use case that walks in. We need to provide a tool
> that operates in a declarative way at build time, but still offers
> users just enough wiggle room to fit Maven responsibly around their
> own needs. Is this a balancing act? Of course it is, and not all of
> the resulting builds will look like elegant masterpieces of design.
> But the alternative is to tell those users, "Sorry, come back later
> when we release a new version that accommodates your use case." We
> have to try to do the right thing, but users absolutely must have
> enough rope to hang themselves, too.
>
> Tightening the usage of @phase will eliminate a lot of critical
> flexibility here.
We'll agree to disagree then.
>
> -john
>
>>>
>>> Benjamin
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>> Thanks,
>> Jason
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> http://twitter.com/SonatypeNexus
>> http://twitter.com/SonatypeM2E
>> ----------------------------------------------------------
>> Our achievements speak for themselves. What we have to keep track
>> of are our failures, discouragements and doubts. We tend to forget
>> the past difficulties, the many false starts, and the painful
>> groping. We see our past achievements as the end result of a
>> clean forward thrust, and our present difficulties as
>> signs of decline and decay.
>> -- Eric Hoffer, Reflections on the Human Condition
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
----------------------------------------------------------
A man enjoys his work when he understands the whole and when he
is responsible for the quality of the whole
-- Christopher Alexander, A Pattern Language
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: executions, phases and multiple goals
Posted by John Casey <jd...@commonjava.org>.
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 default phase binding in this
>> case is confusing. It's just convention over configuration, isn't it?
>
> Changing a source directory does not change the behavior of a build. The
> convention for something designed to be truly pluggable. Changing the
> phase the assembly plugin alters the way it works. There is the weirdo
> magic, as a case in point, where depending on what phase you are in you
> might get a directory or an archive as a resolved artifact. Then you're
> starting to look for files or directories in your plugin ... so I don't
> think this is a case of convention over configuration here. I think a
> mojo is either designed to work doing a single thing in a single phase
> of the lifecycle, or it's a utility player. Assigning a "default" phase
> only to have it be changed by a user likely means the mojo has not been
> tested in this case and will more likely then not cause someone
> confusion or just plain not work. We could even do something like @phase
> package,install if you truly think something belongs and has been tested
> to run in those phases.
I don't think it's more intuitive to have this proliferation of new
mojos, simply to handle explicitly all the potential places where it
might be appropriate to use a particular piece of build logic. As it is
in the assembly plugin, we have five or more mojos (owing to legacy
issues) that do 99% the same thing, but they're named differently to
handle the 1% difference in logic. Actually, the 1% difference is now
accounted for almost completely in the shared code, so the 1% difference
is a legacy notion as well. Now, in your approach, I'll have to create
at least several more mojos to handle cases where people want to use the
assembly plugin in different phases. I simply cannot remove the '@phase'
annotation, because in 80% of cases the user wants to use a
dependencySet which requires dependency resolution, so providing '@phase
package' eliminates configuration (by providing a convention) for 80% of
use cases.
I think it's a mistake to enforce your assumptions about the quality of
tests and/or code in plugins. It would truly be a case of coding for the
lowest common denominator, and imposing a serious penalty on plugins
that have legitimate reasons for leaving the default + configuration in
place.
>
>> The default value saves one from typing and also provides a hint (not
>> a restriction) about the major (but not the one and only) usage of a
>> goal.
>>
>> Hoping that we will leave some decisions to the user, not the tool...
>>
>
> The decisions that can be made by the user have to be options that were
> tested by the developers. If the developer was truly responsible for
> writing a mojo and was somehow made to incur the cost of support then
> I'm willing to bet that they would limit how that mojo was used. I think
> it would be fine to allow a developer to specify all the phases the
> plugin is known to run in and then the user works within the known set
> of viable conditions. I think we need to be very realistic about what
> can be supported and I think this ultimately benefits everyone. If a
> system lets you do something then one should reasonably expect it to
> work. There are already complete free-for-alls for people to use and I
> think we have to consider allowing less but works exactly as advertised.
>
I'm all for this sort of documentation, telling users where a particular
plugin is safe to run. But let's not throw the baby out with the
bathwater here. There are cases where plugins could be used almost
anywhere in the build process (especially if they're not producing
something involved in the "main line" of compiling/testing/etc. the
actual source code). And frankly, there are also cases where some builds
get pretty crowded in certain lifecycle phases, and it's helpful to get
a little creative with phase bindings in cases where something has to
happen "at some point" before something else, but it doesn't necessarily
matter when.
Of course this is a little vague, but that's the point; we cannot
possibly account for every single concrete build use case in the entire
world. We don't have the infrastructure to document them, nor do we want
to engage in the endless rounds of releases required to support that
extra, marginal use case that walks in. We need to provide a tool that
operates in a declarative way at build time, but still offers users just
enough wiggle room to fit Maven responsibly around their own needs. Is
this a balancing act? Of course it is, and not all of the resulting
builds will look like elegant masterpieces of design. But the
alternative is to tell those users, "Sorry, come back later when we
release a new version that accommodates your use case." We have to try
to do the right thing, but users absolutely must have enough rope to
hang themselves, too.
Tightening the usage of @phase will eliminate a lot of critical
flexibility here.
-john
>>
>> Benjamin
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/SonatypeNexus
> http://twitter.com/SonatypeM2E
> ----------------------------------------------------------
>
> Our achievements speak for themselves. What we have to keep track
> of are our failures, discouragements and doubts. We tend to forget
> the past difficulties, the many false starts, and the painful
> groping. We see our past achievements as the end result of a
> clean forward thrust, and our present difficulties as
> signs of decline and decay.
>
> -- Eric Hoffer, Reflections on the Human Condition
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: executions, phases and multiple goals
Posted by Jason van Zyl <jv...@sonatype.com>.
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
> this case is confusing. It's just convention over configuration,
> isn't it?
Changing a source directory does not change the behavior of a build.
The convention for something designed to be truly pluggable. Changing
the phase the assembly plugin alters the way it works. There is the
weirdo magic, as a case in point, where depending on what phase you
are in you might get a directory or an archive as a resolved artifact.
Then you're starting to look for files or directories in your
plugin ... so I don't think this is a case of convention over
configuration here. I think a mojo is either designed to work doing a
single thing in a single phase of the lifecycle, or it's a utility
player. Assigning a "default" phase only to have it be changed by a
user likely means the mojo has not been tested in this case and will
more likely then not cause someone confusion or just plain not work.
We could even do something like @phase package,install if you truly
think something belongs and has been tested to run in those phases.
> The default value saves one from typing and also provides a hint
> (not a restriction) about the major (but not the one and only) usage
> of a goal.
>
> Hoping that we will leave some decisions to the user, not the tool...
>
The decisions that can be made by the user have to be options that
were tested by the developers. If the developer was truly responsible
for writing a mojo and was somehow made to incur the cost of support
then I'm willing to bet that they would limit how that mojo was used.
I think it would be fine to allow a developer to specify all the
phases the plugin is known to run in and then the user works within
the known set of viable conditions. I think we need to be very
realistic about what can be supported and I think this ultimately
benefits everyone. If a system lets you do something then one should
reasonably expect it to work. There are already complete free-for-alls
for people to use and I think we have to consider allowing less but
works exactly as advertised.
>
> Benjamin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
----------------------------------------------------------
Our achievements speak for themselves. What we have to keep track
of are our failures, discouragements and doubts. We tend to forget
the past difficulties, the many false starts, and the painful
groping. We see our past achievements as the end result of a
clean forward thrust, and our present difficulties as
signs of decline and decay.
-- Eric Hoffer, Reflections on the Human Condition
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: executions, phases and multiple goals
Posted by Benjamin Bentmann <be...@udo.edu>.
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 configuration, isn't it?
The default value saves one from typing and also provides a hint (not a
restriction) about the major (but not the one and only) usage of a goal.
Hoping that we will leave some decisions to the user, not the tool...
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: executions, phases and multiple goals
Posted by Jason van Zyl <jv...@sonatype.com>.
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 <jv...@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 specified in the mojo
>>>> itself. If it
>>>> is supposed to flexible wrt where it runs in the lifecycle then
>>>> no phase
>>>> should be specified in the mojo. You're doing something the
>>>> author of the
>>>> mojo did not intend.
>>>>
>>>>
>>> Eh, I would not agree (other than in the case of the failsafe-
>>> maven-plugin)
>>>
>> A user generally wouldn't because you are never saddled with
>> supporting the resulting outcome. I am very much driven by the
>> question what is truly supportable. I want to move more toward what
>> is definitely supported and making extremely clear boundaries like
>> finalizing classes, being strict about lifecycle binding and
>> anything else that makes it clear where you become responsible for
>> your use versus the community. This is my reasoning. No user is
>> ever going to support limiting a behavior they use.
>>> I (as a plugin user) might have a perfectly good reason for re-
>>> binding a
>>> goal to a different phase...
>> Do you?
>> At that point you wander into the same situation we have with
>> people wanting to do anything they want. Then you combine N
>> plugins wired to phases other then what they intended then you've
>> got undocumented, unsupported use. I honestly don't think this
>> benefits anyone. This variance has a very real cost. If we had
>> disallowed this to start with then you as the user would have to
>> talk to the author or make your own version.
>> Some areas may be a little grayer then others but someone trying to
>> bind a mojo that is designated for the generate-sources phases to
>> another phase makes no sense. Every mojo should be that clear cut
>> and if it's not then that's a problem in and of itself.
>
>
> In the case of the assembly plugin, we provide '@phase package' but
> this is really more of a suggestion. If you're using dependencySets,
> then it's a pretty strong suggestion, since moving it up in the
> lifecycle mapping too much could mean resolving dependencies earlier
> in the lifecycle than you really want to.
>
> However, if you're doing source assemblies or something, then you
> can easily bind to the validate phase in many cases without any
> penalty. IMO this is a perfectly appropriate situation. We've
> thought about the costs associated with moving the execution out of
> the package phase, and recognize that in some cases it's no problem
> at all.
>
In these cases then it's where the ambiguity needs to be resolved by
the author and you have the mojo bind to the phase where it's specific
use. So if the source assembly is a use case that has emerged then
make a subclass if only to change the phase. Or if the assembly plugin
is truly a utility player then have no suggested binding. To me it
either has a specific use case in a specific phase, or it can go
anywhere. I think the phase as a suggestion is probably just confusing.
>>> for example I might need to execute something
>>> in-between and therefore shift things back a phase... ok so that
>>> should be a
>>> 2.x problem once 3.x gets the build planning code, but I would
>>> still think
>>> that Maven should not bomb out just because a plugin user has re-
>>> bound the
>>> phase from the default phase for a goal...
>>>
>>> +1 for Maven giving a big fat warning though
>>>
>>> My €0.02 in any case
>>>
>> Noted.
>>> -Stephen
>> Thanks,
>> Jason
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> http://twitter.com/SonatypeNexus
>> http://twitter.com/SonatypeM2E
>> ----------------------------------------------------------
>> the course of true love never did run smooth ...
>> -- Shakespeare
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
----------------------------------------------------------
You are never dedicated to something you have complete confidence in.
No one is fanatically shouting that the sun is going to rise tomorrow.
They know it is going to rise tomorrow. When people are fanatically
dedicated to political or religious faiths or any other kind of
dogmas or goals, it's always because these dogmas or
goals are in doubt.
-- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: executions, phases and multiple goals
Posted by John Casey <jd...@commonjava.org>.
Jason van Zyl wrote:
>
> On 22-May-09, at 11:29 AM, Stephen Connolly wrote:
>
>> 2009/5/22 Jason van Zyl <jv...@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 specified in the mojo itself.
>>> If it
>>> is supposed to flexible wrt where it runs in the lifecycle then no phase
>>> should be specified in the mojo. You're doing something the author of
>>> the
>>> mojo did not intend.
>>>
>>>
>> Eh, I would not agree (other than in the case of the
>> failsafe-maven-plugin)
>>
>
> A user generally wouldn't because you are never saddled with supporting
> the resulting outcome. I am very much driven by the question what is
> truly supportable. I want to move more toward what is definitely
> supported and making extremely clear boundaries like finalizing classes,
> being strict about lifecycle binding and anything else that makes it
> clear where you become responsible for your use versus the community.
> This is my reasoning. No user is ever going to support limiting a
> behavior they use.
>
>> I (as a plugin user) might have a perfectly good reason for re-binding a
>> goal to a different phase...
>
> Do you?
>
> At that point you wander into the same situation we have with people
> wanting to do anything they want. Then you combine N plugins wired to
> phases other then what they intended then you've got undocumented,
> unsupported use. I honestly don't think this benefits anyone. This
> variance has a very real cost. If we had disallowed this to start with
> then you as the user would have to talk to the author or make your own
> version.
>
> Some areas may be a little grayer then others but someone trying to bind
> a mojo that is designated for the generate-sources phases to another
> phase makes no sense. Every mojo should be that clear cut and if it's
> not then that's a problem in and of itself.
In the case of the assembly plugin, we provide '@phase package' but this
is really more of a suggestion. If you're using dependencySets, then
it's a pretty strong suggestion, since moving it up in the lifecycle
mapping too much could mean resolving dependencies earlier in the
lifecycle than you really want to.
However, if you're doing source assemblies or something, then you can
easily bind to the validate phase in many cases without any penalty. IMO
this is a perfectly appropriate situation. We've thought about the costs
associated with moving the execution out of the package phase, and
recognize that in some cases it's no problem at all.
>
>> for example I might need to execute something
>> in-between and therefore shift things back a phase... ok so that
>> should be a
>> 2.x problem once 3.x gets the build planning code, but I would still
>> think
>> that Maven should not bomb out just because a plugin user has re-bound
>> the
>> phase from the default phase for a goal...
>>
>> +1 for Maven giving a big fat warning though
>>
>> My €0.02 in any case
>>
>
> Noted.
>
>> -Stephen
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/SonatypeNexus
> http://twitter.com/SonatypeM2E
> ----------------------------------------------------------
>
> the course of true love never did run smooth ...
>
> -- Shakespeare
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: executions, phases and multiple goals
Posted by Stephen Connolly <st...@gmail.com>.
2009/5/22 Jason van Zyl <jv...@sonatype.com>
>
> On 22-May-09, at 11:29 AM, Stephen Connolly wrote:
>
> 2009/5/22 Jason van Zyl <jv...@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 specified in the mojo itself. If
>>> it
>>> is supposed to flexible wrt where it runs in the lifecycle then no phase
>>> should be specified in the mojo. You're doing something the author of the
>>> mojo did not intend.
>>>
>>>
>>> Eh, I would not agree (other than in the case of the
>> failsafe-maven-plugin)
>>
>>
> A user generally wouldn't because you are never saddled with supporting the
> resulting outcome. I am very much driven by the question what is truly
> supportable. I want to move more toward what is definitely supported and
> making extremely clear boundaries like finalizing classes, being strict
> about lifecycle binding and anything else that makes it clear where you
> become responsible for your use versus the community. This is my reasoning.
> No user is ever going to support limiting a behavior they use.
>
I'm not sure I quite understand what point exactly you are making here
>
>
> I (as a plugin user) might have a perfectly good reason for re-binding a
>> goal to a different phase...
>>
>
> Do you?
>
> At that point you wander into the same situation we have with people
> wanting to do anything they want. Then you combine N plugins wired to
> phases other then what they intended then you've got undocumented,
> unsupported use. I honestly don't think this benefits anyone. This variance
> has a very real cost. If we had disallowed this to start with then you as
> the user would have to talk to the author or make your own version.
>
> Some areas may be a little grayer then others but someone trying to bind a
> mojo that is designated for the generate-sources phases to another phase
> makes no sense. Every mojo should be that clear cut and if it's not then
> that's a problem in and of itself.
>
As a mojo developer I am +1 on this
As a mojo consumer I am -1 on this... but that might just be bad experiences
from Maven 2.x.
Maven 3.x with the build plan could convince me otherwise, but we have the
issue of all the existing projects "out there" that are Maven 2.x
Given that AFAIK 3.x is supposed to build them too I am curious how you
intend to square the circle.
-Stephen
Re: executions, phases and multiple goals
Posted by Jason van Zyl <jv...@sonatype.com>.
On 22-May-09, at 11:29 AM, Stephen Connolly wrote:
> 2009/5/22 Jason van Zyl <jv...@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 specified in the mojo
>> itself. If it
>> is supposed to flexible wrt where it runs in the lifecycle then no
>> phase
>> should be specified in the mojo. You're doing something the author
>> of the
>> mojo did not intend.
>>
>>
> Eh, I would not agree (other than in the case of the failsafe-maven-
> plugin)
>
A user generally wouldn't because you are never saddled with
supporting the resulting outcome. I am very much driven by the
question what is truly supportable. I want to move more toward what is
definitely supported and making extremely clear boundaries like
finalizing classes, being strict about lifecycle binding and anything
else that makes it clear where you become responsible for your use
versus the community. This is my reasoning. No user is ever going to
support limiting a behavior they use.
> I (as a plugin user) might have a perfectly good reason for re-
> binding a
> goal to a different phase...
Do you?
At that point you wander into the same situation we have with people
wanting to do anything they want. Then you combine N plugins wired to
phases other then what they intended then you've got undocumented,
unsupported use. I honestly don't think this benefits anyone. This
variance has a very real cost. If we had disallowed this to start with
then you as the user would have to talk to the author or make your own
version.
Some areas may be a little grayer then others but someone trying to
bind a mojo that is designated for the generate-sources phases to
another phase makes no sense. Every mojo should be that clear cut and
if it's not then that's a problem in and of itself.
> for example I might need to execute something
> in-between and therefore shift things back a phase... ok so that
> should be a
> 2.x problem once 3.x gets the build planning code, but I would still
> think
> that Maven should not bomb out just because a plugin user has re-
> bound the
> phase from the default phase for a goal...
>
> +1 for Maven giving a big fat warning though
>
> My €0.02 in any case
>
Noted.
> -Stephen
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
----------------------------------------------------------
the course of true love never did run smooth ...
-- Shakespeare
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: executions, phases and multiple goals
Posted by Stephen Connolly <st...@gmail.com>.
2009/5/22 Jason van Zyl <jv...@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 specified in the mojo itself. If it
> is supposed to flexible wrt where it runs in the lifecycle then no phase
> should be specified in the mojo. You're doing something the author of the
> mojo did not intend.
>
>
Eh, I would not agree (other than in the case of the failsafe-maven-plugin)
I (as a plugin user) might have a perfectly good reason for re-binding a
goal to a different phase... for example I might need to execute something
in-between and therefore shift things back a phase... ok so that should be a
2.x problem once 3.x gets the build planning code, but I would still think
that Maven should not bomb out just because a plugin user has re-bound the
phase from the default phase for a goal...
+1 for Maven giving a big fat warning though
My €0.02 in any case
-Stephen
Re: executions, phases and multiple goals
Posted by Stephen Connolly <st...@gmail.com>.
2009/5/22 Jason van Zyl <jv...@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
running off telling people "just do this" I wanted to establish if this
behaviour will still work for Maven 3.x...
I am not entirely happy with the syntax myself.... and Brian (on IRC) felt
that an execution [with no phase and two goals which are bound to two
different phases] was ugly and unintuative... which I tend to agree
But if you are chiming in and saying "Oh but of course and Maven 3.x will
explicitly support such a syntax" then I will switch my examples from
<executions>
<execution>
<id>integration-test</id>
<goals>
<goal>integration-test</goal>
</goals>
</execution>
<execution>
<id>verify</id>
<goals>
<goal>verify</goal>
</goals>
</execution>
to
<executions>
<execution>
<goals>
<goal>integration-test</goal>
<goal>verify</goal>
</goals>
</execution>
and rejoyce
-Stephen
Re: executions, phases and multiple goals
Posted by Jason van Zyl <jv...@sonatype.com>.
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 AbstractMojo
> {
> ...
> }
>
> and
>
> /**
> * @goal verify
> * @requiresProject true
> * @requiresDependencyResolution test
> * @phase verify
> */
> public class VerifyMojo
> extends AbstractMojo
> {
> ...
> }
>
>
> If I add to my pom.xml
>
> <project>
> ..
> <build>
> ..
> <plugins>
> ...
> <plugin>
> <groupId>....</groupId>
> <artifactId>....</artifactId>
> <version>...</version>
> ...
> * <executions>
> <execution>
> <goals>
> <goal>integration-test</goal>
> <goal>verify</goal>
> </goals>
> </execution>
> </executions>
> * </plugin>
> ...
> </plugins>
> ...
> </build>
> </project>
>
> Then the integration-test goal is bound to the integration-test
> phase and
> the verify goal is bound to the verify phase.
>
> My question is this... is this a feature or a bug?
>
> 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?
> Just to confirm for everyone...
>
> If I add
>
> <project>
> ..
> <build>
> ..
> <plugins>
> ...
> <plugin>
> <groupId>....</groupId>
> <artifactId>....</artifactId>
> <version>...</version>
> ...
> * <executions>
> <execution>
> <phase>integration-test</phase>
> <goals>
> <goal>integration-test</goal>
> <goal>verify</goal>
> </goals>
> </execution>
> </executions>
> * </plugin>
> ...
> </plugins>
> ...
> </build>
> </project>
>
> 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 the mojo
itself. If it is supposed to flexible wrt where it runs in the
lifecycle then no phase should be specified in the mojo. You're doing
something the author of the mojo did not intend.
> -Stephen
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
----------------------------------------------------------
Simplex sigillum veri. (Simplicity is the seal of truth.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: executions, phases and multiple goals
Posted by Stephen Connolly <st...@gmail.com>.
2009/5/22 Stephen Connolly <st...@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 FailsafeMojo
> extends AbstractMojo
> {
> ...
> }
>
> and
>
> /**
> * @goal verify
> * @requiresProject true
> * @requiresDependencyResolution test
> * @phase verify
> */
> public class VerifyMojo
> extends AbstractMojo
> {
> ...
> }
>
>
> If I add to my pom.xml
>
> <project>
> ..
> <build>
> ..
> <plugins>
> ...
> <plugin>
> <groupId>....</groupId>
> <artifactId>....</artifactId>
> <version>...</version>
> ...
> * <executions>
> <execution>
> <goals>
> <goal>integration-test</goal>
> <goal>verify</goal>
> </goals>
> </execution>
> </executions>
> * </plugin>
> ...
> </plugins>
> ...
> </build>
> </project>
>
> Then the integration-test goal is bound to the integration-test phase and
> the verify goal is bound to the verify phase.
>
> My question is this... is this a feature or a bug?
>
> It'd be nice if it was a feature... but I suspect it is a bug...
>
> Just to confirm for everyone...
>
> If I add
>
> <project>
> ..
> <build>
> ..
> <plugins>
> ...
> <plugin>
> <groupId>....</groupId>
> <artifactId>....</artifactId>
> <version>...</version>
> ...
> * <executions>
> <execution>
> <phase>integration-test</phase>
> <goals>
> <goal>integration-test</goal>
> <goal>verify</goal>
> </goals>
> </execution>
> </executions>
> * </plugin>
> ...
> </plugins>
> ...
> </build>
> </project>
>
> Then both goals are bound to the integration-test phase, as I would expect
>
> -Stephen
<plugins>
<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>maven-jetty-plugin</artifactId>
<version>6.1.16</version>
<configuration>
<stopPort>${integration-test-stop-port}</stopPort>
<stopKey>STOP</stopKey>
<contextPath>/</contextPath>
</configuration>
<executions>
<execution>
<id>start-jetty</id>
<phase>pre-integration-test</phase>
<goals>
<!-- stop any previous instance to free up the port -->
<goal>stop</goal>
<goal>run-exploded</goal>
</goals>
<configuration>
<scanIntervalSeconds>0</scanIntervalSeconds>
<daemon>true</daemon>
</configuration>
</execution>
<execution>
<id>stop-jetty</id>
<phase>post-integration-test</phase>
<goals>
<goal>stop</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>@project.groupId@</groupId>
<artifactId>@project.artifactId@</artifactId>
<version>@project.version@</version>
<executions>
<execution>
<goals>
<goal>integration-test</goal>
<goal>verify</goal>
</goals>
</execution>
</executions>
</plugin>
gives:
...
[INFO] [INFO]* [jetty:run-exploded {execution: start-jetty}]*
[INFO] [INFO] Configuring Jetty for project: run failing tests in jetty
container
[INFO] 2009-05-22 15:48:35.834::INFO: Logging to STDERR via
org.mortbay.log.StdErrLog
[INFO] [INFO] Context path = /
[INFO] [INFO] Tmp directory = determined at runtime
[INFO] [INFO] Web defaults = org/mortbay/jetty/webapp/webdefault.xml
[INFO] [INFO] Web overrides = none
[INFO] [INFO] Starting jetty 6.1.16 ...
[INFO] 2009-05-22 15:48:35.906::INFO: jetty-6.1.16
[INFO] 2009-05-22 15:48:35.999::INFO: No Transaction manager found - if
your webapp requires one, please configure one.
[INFO] 2009-05-22 15:48:36.170::INFO: Started
SelectChannelConnector@0.0.0.0:8080
[INFO] [INFO] Started Jetty Server
[INFO] [INFO] *[failsafe:integration-test {execution: default}]*
[INFO] [INFO] Failsafe report directory:
/home/connollys/src/mojo-sandbox/failsafe-maven-plugin/target/it/jetty-war-test-failing/target/failsafe-reports
[INFO]
[INFO] -------------------------------------------------------
[INFO] T E S T S
[INFO] -------------------------------------------------------
[INFO] Running basic.BasicIT
[INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.896
sec <<< FAILURE!
[INFO]
[INFO] Results :
[INFO]
[INFO] Failed tests:
[INFO] testSmokes(basic.BasicIT)
[INFO]
[INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0
[INFO]
[INFO] [INFO] *[jetty:stop {execution: stop-jetty}]*
[INFO] [INFO] Stopping server 0
[INFO] [INFO]* [failsafe:verify {execution: default}]*
[INFO] [INFO] Failsafe report directory:
/home/connollys/src/mojo-sandbox/failsafe-maven-plugin/target/it/jetty-war-test-failing/target/failsafe-reports
[INFO] [INFO]
------------------------------------------------------------------------
[INFO] [ERROR] BUILD FAILURE
[INFO] [INFO]
------------------------------------------------------------------------
[INFO] [INFO] There are test failures.
[INFO]
Re: executions, phases and multiple goals
Posted by Stephen Connolly <st...@gmail.com>.
2009/5/22 Stephen Connolly <st...@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 FailsafeMojo
> extends AbstractMojo
> {
> ...
> }
>
> and
>
> /**
> * @goal verify
> * @requiresProject true
> * @requiresDependencyResolution test
> * @phase verify
> */
> public class VerifyMojo
> extends AbstractMojo
> {
> ...
> }
>
>
> If I add to my pom.xml
>
> <project>
> ..
> <build>
> ..
> <plugins>
> ...
> <plugin>
> <groupId>....</groupId>
> <artifactId>....</artifactId>
> <version>...</version>
> ...
> * <executions>
> <execution>
> <goals>
> <goal>integration-test</goal>
> <goal>verify</goal>
> </goals>
> </execution>
> </executions>
> * </plugin>
> ...
> </plugins>
> ...
> </build>
> </project>
>
> Then the integration-test goal is bound to the integration-test phase and
> the verify goal is bound to the verify phase.
>
> My question is this... is this a feature or a bug?
>
> It'd be nice if it was a feature... but I suspect it is a bug...
>
> Just to confirm for everyone...
>
> If I add
>
> <project>
> ..
> <build>
> ..
> <plugins>
> ...
> <plugin>
> <groupId>....</groupId>
> <artifactId>....</artifactId>
> <version>...</version>
> ...
> * <executions>
> <execution>
> <phase>integration-test</phase>
> <goals>
> <goal>integration-test</goal>
> <goal>verify</goal>
> </goals>
> </execution>
> </executions>
> * </plugin>
> ...
> </plugins>
> ...
> </build>
> </project>
>
> Then both goals are bound to the integration-test phase, as I would expect
>
> -Stephen
<plugins>
<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>maven-jetty-plugin</artifactId>
<version>6.1.16</version>
<configuration>
<stopPort>${integration-test-stop-port}</stopPort>
<stopKey>STOP</stopKey>
<contextPath>/</contextPath>
</configuration>
<executions>
<execution>
<id>start-jetty</id>
<phase>pre-integration-test</phase>
<goals>
<!-- stop any previous instance to free up the port -->
<goal>stop</goal>
<goal>run-exploded</goal>
</goals>
<configuration>
<scanIntervalSeconds>0</scanIntervalSeconds>
<daemon>true</daemon>
</configuration>
</execution>
<execution>
<id>stop-jetty</id>
<phase>post-integration-test</phase>
<goals>
<goal>stop</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>@project.groupId@</groupId>
<artifactId>@project.artifactId@</artifactId>
<version>@project.version@</version>
<executions>
<execution>
<goals>
<goal>integration-test</goal>
<goal>verify</goal>
</goals>
</execution>
</executions>
</plugin>
gives:
...
[INFO] [INFO]* [jetty:run-exploded {execution: start-jetty}]*
[INFO] [INFO] Configuring Jetty for project: run failing tests in jetty
container
[INFO] 2009-05-22 15:48:35.834::INFO: Logging to STDERR via
org.mortbay.log.StdErrLog
[INFO] [INFO] Context path = /
[INFO] [INFO] Tmp directory = determined at runtime
[INFO] [INFO] Web defaults = org/mortbay/jetty/webapp/webdefault.xml
[INFO] [INFO] Web overrides = none
[INFO] [INFO] Starting jetty 6.1.16 ...
[INFO] 2009-05-22 15:48:35.906::INFO: jetty-6.1.16
[INFO] 2009-05-22 15:48:35.999::INFO: No Transaction manager found - if
your webapp requires one, please configure one.
[INFO] 2009-05-22 15:48:36.170::INFO: Started
SelectChannelConnector@0.0.0.0:8080
[INFO] [INFO] Started Jetty Server
[INFO] [INFO] *[failsafe:integration-test {execution: default}]*
[INFO] [INFO] Failsafe report directory:
/home/connollys/src/mojo-sandbox/failsafe-maven-plugin/target/it/jetty-war-test-failing/target/failsafe-reports
[INFO]
[INFO] -------------------------------------------------------
[INFO] T E S T S
[INFO] -------------------------------------------------------
[INFO] Running basic.BasicIT
[INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.896
sec <<< FAILURE!
[INFO]
[INFO] Results :
[INFO]
[INFO] Failed tests:
[INFO] testSmokes(basic.BasicIT)
[INFO]
[INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0
[INFO]
[INFO] [INFO] *[jetty:stop {execution: stop-jetty}]*
[INFO] [INFO] Stopping server 0
[INFO] [INFO]* [failsafe:verify {execution: default}]*
[INFO] [INFO] Failsafe report directory:
/home/connollys/src/mojo-sandbox/failsafe-maven-plugin/target/it/jetty-war-test-failing/target/failsafe-reports
[INFO] [INFO]
------------------------------------------------------------------------
[INFO] [ERROR] BUILD FAILURE
[INFO] [INFO]
------------------------------------------------------------------------
[INFO] [INFO] There are test failures.
[INFO]