Re: Is --fail-at-end buggy?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Is --fail-at-end buggy?

stephenconnolly
I think we need a fourth option... or maybe more.

If we try to change the existing option we’ll have people crop up who rely
on the current behaviour

On Mon 5 Feb 2018 at 09:14, Tibor Digana <[hidden email]> wrote:

> Maybe I have a fix candidate.
> Lets suppose this command:
>
> $ mvn test --fail-at-end --also-make-dependents
>
> The dependent modules would not be skipped then.
> If you additionally run with "... --project ...", this fix would still make
> sense because once the -amd is applied to list of projects which you want
> to include and then there is no reason to skip them or error if you use
> -fae.
>
> WDYT?
>
>
> On Mon, Feb 5, 2018 at 9:31 AM, Tibor Digana <[hidden email]>
> wrote:
>
> > From user perspective this is our problem.
> >
> > >> With fail-at-end, a module fails but we do not stop independent
> modules
> > from success.
> >
> > Because there the feature is useless in real life.
> > The user does not really have any option to continue with all modules,
> > finally getting exit code 0 or 1.
> >
> >
> > On Mon, Feb 5, 2018 at 9:06 AM, Stephen Connolly <
> > [hidden email]> wrote:
> >
> >> On Sun 4 Feb 2018 at 18:35, Tibor Digana <[hidden email]>
> wrote:
> >>
> >> > So we are on the same way. Shortly speaking both options should build
> >> > modules in the same way but the exit code should be a difference.
> >> > This is problem in my company: We want to execute all unit tests of
> all
> >> > modules but the compiler should not complain since the classes are
> >> pretty
> >> > consistent and can be compiled. We want to get entire picture of all
> >> unit
> >> > tests and Exit Code should be 1 due to the tests fail.
> >>
> >>
> >> So to my mind, fail-never is something different.
> >>
> >> With fail-never all the mojo executions are attempted, so *in theory*
> >> downstream modules may still be able to build.
> >>
> >> With fail-at-end, a module fails but we do not stop independent modules
> >> from success.
> >>
> >> What we want is a halfway house, where we continue executing phases
> after
> >> the failed goal and then fail at the end if any phase failed at all
> >>
> >> >
> >> >
> >> > On Fri, Feb 2, 2018 at 9:21 AM, Robert Scholte <[hidden email]>
> >> > wrote:
> >> >
> >> > > I have the same expectations as Arnaud
> >> > >
> >> > > On Thu, 01 Feb 2018 13:55:20 +0100, Arnaud Héritier <
> >> [hidden email]
> >> > >
> >> > > wrote:
> >> > >
> >> > > yes I think I agree
> >> > >> my expectation would be
> >> > >>
> >> > >>  -fae,--fail-at-end                     Only fail the build
> >> afterwards;
> >> > >> allow all non-impacted builds to continue
> >> > >>
> >> > >> 0 if no problem, 1 if any module failed
> >> > >>
> >> > >>  -ff,--fail-fast                        Stop at first failure in
> >> > >> reactorized builds
> >> > >>
> >> > >> 0 if no problem, 1 if failed
> >> > >>
> >> > >>  -fn,--fail-never                       NEVER fail the build,
> >> regardless
> >> > >> of
> >> > >> project result
> >> > >>
> >> > >> Always 0
> >> > >>
> >> > >>
> >> > >> On Thu, Feb 1, 2018 at 1:06 PM, Tibor Digana <
> [hidden email]
> >> >
> >> > >> wrote:
> >> > >>
> >> > >> I think this is bug (mvn --fail-at-end) because intermediate
> modules
> >> are
> >> > >>> skipped. Unlike --fail-never runs all modules but returns exit 0.
> I
> >> > want
> >> > >>> exit 1 with --fail-at-end .
> >> > >>>
> >> > >>> WDYT?
> >> > >>>
> >> > >>> Cheers
> >> > >>> Tibor
> >> > >>>
> >> > >>>
> >> > >>
> >> > >>
> >> > >
> ---------------------------------------------------------------------
> >> > > To unsubscribe, e-mail: [hidden email]
> >> > > For additional commands, e-mail: [hidden email]
> >> > >
> >> > >
> >> >
> >> --
> >> Sent from my phone
> >>
> >
> >
>
--
Sent from my phone
Reply | Threaded
Open this post in threaded view
|

Re: Is --fail-at-end buggy?

Tibor Digana-2
Then let's think about a name of new option, e.g. --execute-completely.
WDYT?

On Mon, Feb 5, 2018 at 3:15 PM, Stephen Connolly <
[hidden email]> wrote:

> I think we need a fourth option... or maybe more.
>
> If we try to change the existing option we’ll have people crop up who rely
> on the current behaviour
>
> On Mon 5 Feb 2018 at 09:14, Tibor Digana <[hidden email]> wrote:
>
> > Maybe I have a fix candidate.
> > Lets suppose this command:
> >
> > $ mvn test --fail-at-end --also-make-dependents
> >
> > The dependent modules would not be skipped then.
> > If you additionally run with "... --project ...", this fix would still
> make
> > sense because once the -amd is applied to list of projects which you want
> > to include and then there is no reason to skip them or error if you use
> > -fae.
> >
> > WDYT?
> >
> >
> > On Mon, Feb 5, 2018 at 9:31 AM, Tibor Digana <[hidden email]>
> > wrote:
> >
> > > From user perspective this is our problem.
> > >
> > > >> With fail-at-end, a module fails but we do not stop independent
> > modules
> > > from success.
> > >
> > > Because there the feature is useless in real life.
> > > The user does not really have any option to continue with all modules,
> > > finally getting exit code 0 or 1.
> > >
> > >
> > > On Mon, Feb 5, 2018 at 9:06 AM, Stephen Connolly <
> > > [hidden email]> wrote:
> > >
> > >> On Sun 4 Feb 2018 at 18:35, Tibor Digana <[hidden email]>
> > wrote:
> > >>
> > >> > So we are on the same way. Shortly speaking both options should
> build
> > >> > modules in the same way but the exit code should be a difference.
> > >> > This is problem in my company: We want to execute all unit tests of
> > all
> > >> > modules but the compiler should not complain since the classes are
> > >> pretty
> > >> > consistent and can be compiled. We want to get entire picture of all
> > >> unit
> > >> > tests and Exit Code should be 1 due to the tests fail.
> > >>
> > >>
> > >> So to my mind, fail-never is something different.
> > >>
> > >> With fail-never all the mojo executions are attempted, so *in theory*
> > >> downstream modules may still be able to build.
> > >>
> > >> With fail-at-end, a module fails but we do not stop independent
> modules
> > >> from success.
> > >>
> > >> What we want is a halfway house, where we continue executing phases
> > after
> > >> the failed goal and then fail at the end if any phase failed at all
> > >>
> > >> >
> > >> >
> > >> > On Fri, Feb 2, 2018 at 9:21 AM, Robert Scholte <
> [hidden email]>
> > >> > wrote:
> > >> >
> > >> > > I have the same expectations as Arnaud
> > >> > >
> > >> > > On Thu, 01 Feb 2018 13:55:20 +0100, Arnaud Héritier <
> > >> [hidden email]
> > >> > >
> > >> > > wrote:
> > >> > >
> > >> > > yes I think I agree
> > >> > >> my expectation would be
> > >> > >>
> > >> > >>  -fae,--fail-at-end                     Only fail the build
> > >> afterwards;
> > >> > >> allow all non-impacted builds to continue
> > >> > >>
> > >> > >> 0 if no problem, 1 if any module failed
> > >> > >>
> > >> > >>  -ff,--fail-fast                        Stop at first failure in
> > >> > >> reactorized builds
> > >> > >>
> > >> > >> 0 if no problem, 1 if failed
> > >> > >>
> > >> > >>  -fn,--fail-never                       NEVER fail the build,
> > >> regardless
> > >> > >> of
> > >> > >> project result
> > >> > >>
> > >> > >> Always 0
> > >> > >>
> > >> > >>
> > >> > >> On Thu, Feb 1, 2018 at 1:06 PM, Tibor Digana <
> > [hidden email]
> > >> >
> > >> > >> wrote:
> > >> > >>
> > >> > >> I think this is bug (mvn --fail-at-end) because intermediate
> > modules
> > >> are
> > >> > >>> skipped. Unlike --fail-never runs all modules but returns exit
> 0.
> > I
> > >> > want
> > >> > >>> exit 1 with --fail-at-end .
> > >> > >>>
> > >> > >>> WDYT?
> > >> > >>>
> > >> > >>> Cheers
> > >> > >>> Tibor
> > >> > >>>
> > >> > >>>
> > >> > >>
> > >> > >>
> > >> > >
> > ---------------------------------------------------------------------
> > >> > > To unsubscribe, e-mail: [hidden email]
> > >> > > For additional commands, e-mail: [hidden email]
> > >> > >
> > >> > >
> > >> >
> > >> --
> > >> Sent from my phone
> > >>
> > >
> > >
> >
> --
> Sent from my phone
>



--
Cheers
Tibor
Reply | Threaded
Open this post in threaded view
|

Re: Is --fail-at-end buggy?

Tibor Digana
 (sorry for previous sender email)

Then let's think about a name of new option, e.g. --execute-completely.

WDYT?


On Mon, Feb 5, 2018 at 3:53 PM, Tibor Digana <[hidden email]>
wrote:

> Then let's think about a name of new option, e.g. --execute-completely.
> WDYT?
>
> On Mon, Feb 5, 2018 at 3:15 PM, Stephen Connolly <
> [hidden email]> wrote:
>
>> I think we need a fourth option... or maybe more.
>>
>> If we try to change the existing option we’ll have people crop up who rely
>> on the current behaviour
>>
>> On Mon 5 Feb 2018 at 09:14, Tibor Digana <[hidden email]> wrote:
>>
>> > Maybe I have a fix candidate.
>> > Lets suppose this command:
>> >
>> > $ mvn test --fail-at-end --also-make-dependents
>> >
>> > The dependent modules would not be skipped then.
>> > If you additionally run with "... --project ...", this fix would still
>> make
>> > sense because once the -amd is applied to list of projects which you
>> want
>> > to include and then there is no reason to skip them or error if you use
>> > -fae.
>> >
>> > WDYT?
>> >
>> >
>> > On Mon, Feb 5, 2018 at 9:31 AM, Tibor Digana <[hidden email]>
>> > wrote:
>> >
>> > > From user perspective this is our problem.
>> > >
>> > > >> With fail-at-end, a module fails but we do not stop independent
>> > modules
>> > > from success.
>> > >
>> > > Because there the feature is useless in real life.
>> > > The user does not really have any option to continue with all modules,
>> > > finally getting exit code 0 or 1.
>> > >
>> > >
>> > > On Mon, Feb 5, 2018 at 9:06 AM, Stephen Connolly <
>> > > [hidden email]> wrote:
>> > >
>> > >> On Sun 4 Feb 2018 at 18:35, Tibor Digana <[hidden email]>
>> > wrote:
>> > >>
>> > >> > So we are on the same way. Shortly speaking both options should
>> build
>> > >> > modules in the same way but the exit code should be a difference.
>> > >> > This is problem in my company: We want to execute all unit tests of
>> > all
>> > >> > modules but the compiler should not complain since the classes are
>> > >> pretty
>> > >> > consistent and can be compiled. We want to get entire picture of
>> all
>> > >> unit
>> > >> > tests and Exit Code should be 1 due to the tests fail.
>> > >>
>> > >>
>> > >> So to my mind, fail-never is something different.
>> > >>
>> > >> With fail-never all the mojo executions are attempted, so *in theory*
>> > >> downstream modules may still be able to build.
>> > >>
>> > >> With fail-at-end, a module fails but we do not stop independent
>> modules
>> > >> from success.
>> > >>
>> > >> What we want is a halfway house, where we continue executing phases
>> > after
>> > >> the failed goal and then fail at the end if any phase failed at all
>> > >>
>> > >> >
>> > >> >
>> > >> > On Fri, Feb 2, 2018 at 9:21 AM, Robert Scholte <
>> [hidden email]>
>> > >> > wrote:
>> > >> >
>> > >> > > I have the same expectations as Arnaud
>> > >> > >
>> > >> > > On Thu, 01 Feb 2018 13:55:20 +0100, Arnaud Héritier <
>> > >> [hidden email]
>> > >> > >
>> > >> > > wrote:
>> > >> > >
>> > >> > > yes I think I agree
>> > >> > >> my expectation would be
>> > >> > >>
>> > >> > >>  -fae,--fail-at-end                     Only fail the build
>> > >> afterwards;
>> > >> > >> allow all non-impacted builds to continue
>> > >> > >>
>> > >> > >> 0 if no problem, 1 if any module failed
>> > >> > >>
>> > >> > >>  -ff,--fail-fast                        Stop at first failure in
>> > >> > >> reactorized builds
>> > >> > >>
>> > >> > >> 0 if no problem, 1 if failed
>> > >> > >>
>> > >> > >>  -fn,--fail-never                       NEVER fail the build,
>> > >> regardless
>> > >> > >> of
>> > >> > >> project result
>> > >> > >>
>> > >> > >> Always 0
>> > >> > >>
>> > >> > >>
>> > >> > >> On Thu, Feb 1, 2018 at 1:06 PM, Tibor Digana <
>> > [hidden email]
>> > >> >
>> > >> > >> wrote:
>> > >> > >>
>> > >> > >> I think this is bug (mvn --fail-at-end) because intermediate
>> > modules
>> > >> are
>> > >> > >>> skipped. Unlike --fail-never runs all modules but returns exit
>> 0.
>> > I
>> > >> > want
>> > >> > >>> exit 1 with --fail-at-end .
>> > >> > >>>
>> > >> > >>> WDYT?
>> > >> > >>>
>> > >> > >>> Cheers
>> > >> > >>> Tibor
>> > >> > >>>
>> > >> > >>>
>> > >> > >>
>> > >> > >>
>> > >> > >
>> > ---------------------------------------------------------------------
>> > >> > > To unsubscribe, e-mail: [hidden email]
>> > >> > > For additional commands, e-mail: [hidden email]
>> > >> > >
>> > >> > >
>> > >> >
>> > >> --
>> > >> Sent from my phone
>> > >>
>> > >
>> > >
>> >
>> --
>> Sent from my phone
>>
>
>
>
> --
> Cheers
> Tibor
>