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 <[email protected]> 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 <[email protected]> > 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 < > > [email protected]> wrote: > > > >> On Sun 4 Feb 2018 at 18:35, Tibor Digana <[email protected]> > 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 <[email protected]> > >> > wrote: > >> > > >> > > I have the same expectations as Arnaud > >> > > > >> > > On Thu, 01 Feb 2018 13:55:20 +0100, Arnaud Héritier < > >> [email protected] > >> > > > >> > > 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 < > [email protected] > >> > > >> > >> 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: [email protected] > >> > > For additional commands, e-mail: [email protected] > >> > > > >> > > > >> > > >> -- > >> Sent from my phone > >> > > > > > -- Sent from my phone
