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
