Re: [VOTE] Reset Maven Core, Integration Tests and Resolver repository master branches

+1 On Wed, Jan 4, 2017 at 1:16 PM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > Hi, > > We have collectively managed to mess up our ability to follow the original > release plan for 3.4.0 which was originally supposed to consist of an > effective no-op change of Eclipse's Aether

Re: Lets talk about our changes openly. maven-surefire git commit: [SUREFIRE-1324] Surefire incorrectly suppresses exceptions when closing resources.

Am 01/08/17 um 05:40 schrieb Tibor Digana: > *exception except for System.exit or Runtime.halt, I have 100% guarantee > that finally block is executed anyway. The finally block is guaranteed to be executed no matter what. It is always executed. That's even specified in the JLS. try {

Re: Lets talk about our changes openly. maven-surefire git commit: [SUREFIRE-1324] Surefire incorrectly suppresses exceptions when closing resources.

Am 01/08/17 um 05:20 schrieb Tibor Digana: > There is also no reason to close a stream twice due to the close() is in > finally does always the close. > No reason to call close() and resource= null before *} finally {* and call > close() within *finally *the second time. It's not called twice.

Re: Lets talk about our changes openly. maven-surefire git commit: [SUREFIRE-1324] Surefire incorrectly suppresses exceptions when closing resources.

>>The flush really is not needed. If removing a call to the flush method introduces an issue, the real issue really is a missing call to close. Therefore there is* finally block* because the *#close()* is called anyway if placed in *finally block*, even if the read/write/close/flush threw an

Re: Lets talk about our changes openly. maven-surefire git commit: [SUREFIRE-1324] Surefire incorrectly suppresses exceptions when closing resources.

There is also no reason to close a stream twice due to the close() is in finally does always the close. No reason to call close() and resource= null before *} finally {* and call close() within *finally *the second time. *ConsoleOutputFileReporter.java is missing flush at L69 because of

Re: Lets talk about our changes openly. maven-surefire git commit: [SUREFIRE-1324] Surefire incorrectly suppresses exceptions when closing resources.

Am 01/08/17 um 04:34 schrieb Christian Schulte: > into. I wonder if Findbugs would have warned about it. If things like No. It does not. - To unsubscribe,

Re: Lets talk about our changes openly. maven-surefire git commit: [SUREFIRE-1324] Surefire incorrectly suppresses exceptions when closing resources.

Am 01/08/17 um 04:04 schrieb Tibor Digana: > Currently Jenkins build fails on OOM not because of I/O streams but because > of missing this code > > ThreadedStreamConsumer which was introduced by Kristian Roselvold with > a purpose. > > Now we can do it better using LinkedBlockingQueue

Re: Lets talk about our changes openly. maven-surefire git commit: [SUREFIRE-1324] Surefire incorrectly suppresses exceptions when closing resources.

Currently Jenkins build fails on OOM not because of I/O streams but because of missing this code ThreadedStreamConsumer which was introduced by Kristian Roselvold with a purpose. Now we can do it better using LinkedBlockingQueue put()/take(). public void consumeLine( String s ) {

Re: Lets talk about our changes openly. maven-surefire git commit: [SUREFIRE-1324] Surefire incorrectly suppresses exceptions when closing resources.

Am 01/08/17 um 03:28 schrieb Tibor Digana: > As an example flush() is missing in RunEntryStatisticsMap.java L130. > Maybe I would find more but this is not the only case. There are 24 files > changed. It's not missing there. Close is guaranteed to perform a flush implicitly. resource.flush();

Re: Lets talk about our changes openly. maven-surefire git commit: [SUREFIRE-1324] Surefire incorrectly suppresses exceptions when closing resources.

Am 01/08/17 um 03:18 schrieb Tibor Digana: > Currently I have two clone o master. The HEAD and 4d36 and I see the > difference on the file system. > > I think this is wrong: > reader.close() > reader = null; > finally { The only situation for reader != null here is when the try block has not

Re: Lets talk about our changes openly. maven-surefire git commit: [SUREFIRE-1324] Surefire incorrectly suppresses exceptions when closing resources.

IIUYC your point is to see thrown IOException after close(). No problem to accomplish this. There are 98 occurrences of such calls altogether, but the context of the code must guarantee that the plugin would not hang and it would fail gracefully on internal issue. WDYT? On Sun, Jan 8, 2017 at

Re: Lets talk about our changes openly. maven-surefire git commit: [SUREFIRE-1324] Surefire incorrectly suppresses exceptions when closing resources.

As an example flush() is missing in RunEntryStatisticsMap.java L130. Maybe I would find more but this is not the only case. There are 24 files changed. On Sun, Jan 8, 2017 at 3:19 AM, Tibor Digana-2 [via Maven] < ml-node+s40175n589188...@n5.nabble.com> wrote: > Currently I have two clone o

Re: Lets talk about our changes openly. maven-surefire git commit: [SUREFIRE-1324] Surefire incorrectly suppresses exceptions when closing resources.

Currently I have two clone o master. The HEAD and 4d36 and I see the difference on the file system. I think this is wrong: reader.close() reader = null; finally { IOUtils.close(reader); } I know that IOUtils swallows exception on close(). I agree that better would be method () throws IOException

Re: Lets talk about our changes openly. maven-surefire git commit: [SUREFIRE-1324] Surefire incorrectly suppresses exceptions when closing resources.

Am 01/08/17 um 02:43 schrieb Christian Schulte: > Am 01/08/17 um 01:27 schrieb Tibor Digana: >> You committed right after me and you have reverted two Jira issue. > > This would not have been possible. What reverts are you talking about. I > am locking at >

Re: Lets talk about our changes openly. maven-surefire git commit: [SUREFIRE-1324] Surefire incorrectly suppresses exceptions when closing resources.

Am 01/08/17 um 02:54 schrieb Tibor Digana: > I did amend the commit to prevent from having two commits per one issue. > The reason behind is that we agreed that I will open PR at GitHub and let > you to agree or disagree. Nobody replied with yes or no after cca 9 hours > which looked like nobody

Re: Lets talk about our changes openly. maven-surefire git commit: [SUREFIRE-1324] Surefire incorrectly suppresses exceptions when closing resources.

I did amend the commit to prevent from having two commits per one issue. The reason behind is that we agreed that I will open PR at GitHub and let you to agree or disagree. Nobody replied with yes or no after cca 9 hours which looked like nobody had objections. Usually I am doing fresh clone from

Re: Lets talk about our changes openly. maven-surefire git commit: [SUREFIRE-1324] Surefire incorrectly suppresses exceptions when closing resources.

Am 01/08/17 um 01:27 schrieb Tibor Digana: > You committed right after me and you have reverted two Jira issue. This would not have been possible. What reverts are you talking about. I am locking at . > I do not want to continue until

[GitHub] maven-surefire issue #114: Parallel runner should not drop away runners that...

Github user Tibor17 commented on the issue: https://github.com/apache/maven-surefire/pull/114 I have this PR in my mind, do not worry. The problem is that we may cleanup our codeline and I do not want to loose your path in master after we revert. Pls wait few days. On

Re: Lets talk about our changes openly. maven-surefire git commit: [SUREFIRE-1324] Surefire incorrectly suppresses exceptions when closing resources.

Am 01/08/17 um 01:49 schrieb Fred Cooke: > Christian, some (potentially unwelcome) advice: Learn to use rebase, learn > to fetch, never pull, and review your changes in their new context before > pushing them. I just wasn't used to someone git push --force. As we discussed on dev@, it would have

Re: Lets talk about our changes openly. maven-surefire git commit: [SUREFIRE-1324] Surefire incorrectly suppresses exceptions when closing resources.

I am not going to proceed any further. ☺ I have asked Robert as a chairman and Herve to moderate our cowork. Thx. On Sun, Jan 8, 2017 at 1:50 AM, Fred Cooke [via Maven] < ml-node+s40175n5891853...@n5.nabble.com> wrote: > Christian, some (potentially unwelcome) advice: Learn to use rebase, learn

Re: Lets talk about our changes openly. maven-surefire git commit: [SUREFIRE-1324] Surefire incorrectly suppresses exceptions when closing resources.

Christian, some (potentially unwelcome) advice: Learn to use rebase, learn to fetch, never pull, and review your changes in their new context before pushing them. Whether you take the advice, or not, this is how I ensure that my changes are clean and focused and coherent, every time. Pull is a

Re: Lets talk about our changes openly. maven-surefire git commit: [SUREFIRE-1324] Surefire incorrectly suppresses exceptions when closing resources.

You committed right after me and you have reverted two Jira issue. I do not want to continue until we make agreement. If you want to see thrown IOException, then we can use InputStream.close() instead of IOUtils.close(). Please nobody commit until we know what we clarify. Except for PrintWriter

Re: Lets talk about our changes openly. maven-surefire git commit: [SUREFIRE-1324] Surefire incorrectly suppresses exceptions when closing resources.

Am 01/07/17 um 04:00 schrieb Tibor Digana: > I have created a pull request > https://github.com/apache/maven-surefire/pull/139 > The build passed successfully. > Christian, Benedikt please have a look and I will amend the HEAD revision > in origin/master. > Thx. Damn it. I did not read your

[GitHub] maven-surefire issue #114: Parallel runner should not drop away runners that...

Github user szpak commented on the issue: https://github.com/apache/maven-surefire/pull/114 @Tibor17 Is there something else that prevent that PR from being merged? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your

[GitHub] maven-surefire pull request #139: [SUREFIRE-1324] Surefire incorrectly suppr...

Github user Tibor17 closed the pull request at: https://github.com/apache/maven-surefire/pull/139 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the

Re: [VOTE] Reset Maven Core, Integration Tests and Resolver repository master branches

I'll give the vote until monday just in case anyone missed it On 4 January 2017 at 12:16, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > Hi, > > We have collectively managed to mess up our ability to follow the original > release plan for 3.4.0 which was originally supposed to

[GitHub] maven-surefire issue #139: [SUREFIRE-1324] Surefire incorrectly suppresses e...

Github user Tibor17 commented on the issue: https://github.com/apache/maven-surefire/pull/139 @britter @ChristianSchulte If you have no objections to this I will push it to master. Thx. --- If your project is set up for it, you can reply to this email and have your reply