Why then you did not provide logs in Jira? MasterProcessCommand.java would behave with or without your change because the read() method will always wait for at least one byte to read. The only exception is read(byte[]) will return 0 if and only if byte[] length is 0. Other problems with the commit is removed flushing of streams. Another problem is closing stream after the stream threw exception. Once it threw IOException, closing the stream would throw exception again. Check the ITs again with latest snapshot version 2.19.2-SNAPSHOT and lookup *.dump or *.dumpstream files. The exception which were swallowed in previous versions should appear in dump files.
We should prove every error with exception and then provide a fix but not opposite. And this starcktrace should be in Jira as well. Otherwise how can we know what it was about and root causes and how to reproduce it again, etc. Btw. did you call checkError () and did you dump the trace to a dump file? You see all these things could be discussed in PR and commit could be followed right after. But we are doing opposite process. That's the problem. On Mon, Jan 2, 2017 at 6:29 PM, Christian Schulte <c...@schulte.it> wrote: > On a side note to this: I am getting quite a few IT failures building > surefire locally with Maven 3.3.9 also without that commit. If surefire > is unreliable, Maven is unreliable. > > Am 01/02/17 um 18:22 schrieb Christian Schulte: > > And now everyone please take a look at that commit and tell me what is > > so hard about it to review? You are not able to scroll through this and > > verify what is going on? It's something very trivial. > > > > <https://git1-us-west.apache.org/repos/asf?p=maven- > surefire.git;a=commitdiff;h=e5a6b9c8d4f514100a01dea2acf1fb059e294968> > > > > What does this have to do with a playground? > > > > If you want to know the motivation behind this: > > It's nearly impossible to get the build jobs on the CI system running > > reliable. Most of the time the tests are failing with some message like > > "The VM did not say properly goodbye." I checked out surefire, started > > to read some code and noticed some of the usual suspects I just fixed > > the same way I do it with any other project. Not just Maven. > > > > o Incorrect use of the various incarnations of IOUtil.close. They > > manifest in suppressing exceptions silently although closing resources > > may throw an exception needed to be handled. Surefire has target 1.6, if > > it would have target 1.7, I would have updated it to use the > > try-with-resources statement. > > > > o Incorrect use of the various InputStream.read and such methods. It's > > not ok to just test read > 0. 0 is a valid return value. It's in the > > update to > > /surefire-api/src/main/java/org/apache/maven/surefire/ > booter/MasterProcessCommand.java. > > That can already be the case for the sporadic failures. > > > > o Use of PrintStream without checking the error state. > > > > I would now start to take a look if I can find the reason for those > > sporadic failures and try if I can fix it. With these usual suspects in > > the code, nothing of this makes any sense. That's like searching for an > > issue although you already know there is something wrong at various > places. > > > > What is not open about those changes? It could not be more transparent > > than that. Really. > > > > Am 01/02/17 um 15:42 schrieb Tibor Digana: > >> I also have such feeling that Maven became a playground. > >> Last week I saw it in reality and after Robert told me we made > playground > >> in our sources I could not believe this could happen in such > professional > >> project like Maven. > >> > >> I would appreciate it if the change [1] > >> e5a6b9c8d4f514100a01dea2acf1fb059e294968 was reverted in Surefire and > a new > >> pull request was open at GitHub making the code review. > >> I use to do this with myself with big changes and I am waiting for > anyone > >> in the PR. We are doing the same with one excellent guy from another ASF > >> project who is supporting us with JUnit 5 addons and this works pretty > well. > >> > >> The situation in Surefire is quite ambitious to release Versions 2.19.2 > and > >> 3.0.0-RC1 in parallel with 2.19.3 JDK9 support and JUnit 5 support now > in > >> January. > >> > >> The problem is that these Surefire three plugins are so easy to crash > with > >> whatever changes and therefore I implemented dumping internal errors to > >> dump files which will help us investigate two Jira issues - critical and > >> blocker. And there are much more thinks to talk about the features... > >> > >> I would really appreciate if we could behave like ordinal users in our > >> project and provide a pull request in GitHub and call for code review. > >> This does not mean only Surefire. > >> > >> So now please revert last change [1] and let's start from the ground. > >> We should again learn from the beginning and start communicating in the > >> community; otherwise this is the end of the project. > >> > >> [1] > >> https://git1-us-west.apache.org/repos/asf?p=maven- > surefire.git&a=commit&h=e5a6b9c8d4f514100a01dea2acf1fb059e294968 > >> > >> We can talk about more visions, or I can open Wiki for such talks which > I > >> think we will appreciate because everybody can add her/his visions. > >> > >> WDYT? > >> > >> Cheers > >> Tibor > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Cheers Tibor
