Delany,
you are completely misunderstanding my use case. I am building with
every push, that is the pain, because I have a choice to
-- either see all test results with '-fn' but get a wrong build result
(passed)
-- or fewer test results with '-fae' and a correct build result
(failed).
I do *not* wish to run tests in a later phase. I have no idea where you
got that idea from. I simply want the build to continue for modules
dependent on ones with failing tests, so I can find out if they build
successfully and whether or not they also have failing tests. Then in
the end, after all modules have been built and all tests run (for those
modules which could actually be built without compile errors, of
course), I want to see an overall test result and a properly failed
build. In plain English: I want what '-fae' always should have done to
begin with. I really don't know what is so difficult to understand about
this simple requirement: build as much as possible, test as much as
possible, then report the correct result at the end. I want failed tests
to fail the build in the end, but I do not want them to keep dependent
modules from being built and tested.
--
Alexander Kriegisch
https://scrum-master.de
Delany schrieb am 26.02.2022 14:17 (GMT +07:00):
> Oh its not, im just being thorough.
> It just seems like your build iteration isn't frequent enough. If you're
> not building on every MR/PR or with every push, maybe you need a separate
> test build. Or maybe your reactor is too large and you need to split it
> into separate projects. You could also leave the reactor but build via a
> script that looks for pom files and tests them one at a time. Ugly, but
> effective.
> Bottom line is that install and deploy phases don't create dependencies
> within a reactor, so its no biggy that they delay their execution until
> after. Anything that happens before then does, and its not unreasonable to
> expect development to work within that constraint.
> Delany
>
>
> On Fri, 25 Feb 2022 at 19:40, Alexander Kriegisch <alexan...@kriegisch.name>
> wrote:
>
>> Thanks for digging, Delany. However, I am failing to see how this is
>> meant to solve my problem. Could you elaborate, please?
>> --
>> Alexander Kriegisch
>> https://scrum-master.de
>>
>>
>> Delany schrieb am 25.02.2022 18:05 (GMT +07:00):
>>
>> > Alexander, here it is: https://github.com/raydac/mvn-finisher
>> > Delany
>> >
>> > On Mon, 7 Feb 2022 at 08:17, Delany <delany.middle...@gmail.com> wrote:
>> >
>> >> Someone already wrote an "at end maven plugin". I used it for a while
>> but
>> >> removed it. Can't for the life of me find it in
>> >> github/google/confluence/git log. Sorry!
>> >> Delany
>> >>
>> >>
>> >> On Mon, 7 Feb 2022 at 04:38, Alexander Kriegisch <
>> alexan...@kriegisch.name>
>> >> wrote:
>> >>
>> >>> >> In case you are ready to make you own plugin, it is relatively easy.
>> >>>
>> >>> I am not, Lasse. I also want this to work on the command line and not
>> >>> depend on CI-system-specific workarounds. But thank you for your
>> >>> insightful ideas, I really appreciate them.
>> >>>
>> >>> Tibor, actually I wanted to avoid a potentially lengthy debate on basic
>> >>> principles, but I agree on having one, if you feel it is necessary. I
>> >>> owe you that much, because it tells me that you are not taking design
>> >>> decisions lightly. So if I can contribute to your decision-making
>> >>> process, I shall humbly do so. Not being a Maven (plugin) developer
>> >>> myself, but rather a just user with a bit of background knowledge, I in
>> >>> fact did previously in this thread comment on the two famous '*AtEnd'
>> >>> precedence cases already:
>> >>>
>> >>> >>>> Install and Deploy plugins (...): 'installAtEnd' and 'deployAtEnd'
>> >>> >>>> are blessings IMO, and they are cornerstones of my work, because
>> >>> >>>> they help to avoid half-installed and - even worse - half-deployed
>> >>> >>>> multi-module projects which would lead to inconsistencies in
>> >>> >>>> repositories and might be hard to rectify in remote repositories,
>> >>> >>>> "burning" release numbers unnecessarily.
>> >>>
>> >>> The gist is: Those '*AtEnd' features have user value. If you say that
>> >>> they might be difficult to maintain and shield against side effects, I
>> >>> have to take your word for it. So we have a trade-off situation here,
>> >>> chances vs risks. As the person requesting such a feature, of course I
>> >>> have a chances bias. As a plugin maintainer, of course you take a more
>> >>> conservative or defensive stance. I understand that. In the end, it is
>> >>> your decision. Hopefully others here can contribute more substantially
>> >>> to the discussion than I can.
>> >>>
>> >>> --
>> >>> Alexander Kriegisch
>> >>> https://scrum-master.de
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> >>> For additional commands, e-mail: users-h...@maven.apache.org
>> >>>
>> >>>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
