I understand your use case Alex, just not your process. As this is the users list Im not about to solve the issue of a missing --fail-all-at-end switch, but I could try to think of workarounds. Delany
On Sat, 26 Feb 2022 at 09:32, Alexander Kriegisch <alexan...@kriegisch.name> wrote: > 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 > >
