Am 01/02/17 um 18:45 schrieb Tibor Digana: > 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.
Last time I checked the source code of the JDK, that read method was a call to the OS native method. This could have changed. > Other problems with the commit is removed flushing of streams. Close does a flush implicitly. Doing whatever.flush(); whatever.close(); the flush is not needed. > Another problem is closing stream after the stream threw exception. Once it > threw IOException, closing the stream would throw exception again. That's why I changed 'jos.close()' to 'IOUtil.close(jos)' in the finally clause in the following file, for example. /maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/ForkConfiguration.java. Not sure I get what you mean by this. Close is the last call in the try statement and that may throw an exception that must not be ignored. The resource is set to null as the last statement in the try block. If that last statement is reached (resource == null), you now the try block completed successfully. If the try block does not succeed, the resource will not equal null and the finally block just cleans up suppressing any exceptions to not swallow the exception known to have been thrown in the try block. We do not need to discuss how the IOUtil.close methods are meant to be used, do we? The commons-io Javadoc for those methods contain lots of examples, if in doubt. > 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. I do get fetch && git pull whenever I start doing something and multiple times in between, whenever I notice a commit email got send. I'll run the ITs again and will provide a log here on the list. > > 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? Why do you not just make the appropriate changes then? You can do that even faster than I could. I am writing way more email than code for no reason. There is nothing to dicuss about it. You notice I did not follow your latest changes. So make it fit and leave a descriptive commit message around. JIRA will send out emails. You could even mention other developers in the commit message so that JIRA notifies others. We do not need to discuss every little change. > > 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. The problem is that we are disussing things to death instead of just getting the job done. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
