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

[Tibor Digana]

+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 for the code after migration to
> Apache's Maven Resolver plus some other orthogonal changes around logging
> colourization and launcher script bug fixes.
>
> Given that some developer private builds of the current master branch have
> been shared with as 3.4.0-SNAPSHOT. More critically, JIRA issues have been
> closed with a fixed version of 3.4.0.
>
> For us to release a 3.4.0 with those fixes reverted, could cause confusion
> with our user community.
>
> Additionally the informal practice of keeping existing integration tests as
> RTC has not been followed, leading to some people to question whether the
> integration tests remain valid.
>
> For all the above reasons it is proposed to do *all* the following as an
> whole:
>
> 1. In git://git.apache.org/maven.git we will rename the current master
> branch to `pre-reset-master` and recreate `master`
> as bce33aa2662a51d18cb00347cf2fb174dc195fb1 (
> https://github.com/apache/maven/commit/bce33aa2662a51d18cb00347cf2fb1
> 74dc195fb1
> )
>
> 2. In git://git.apache.org/maven-integration-testing.git we will rename
> the
> current master branch to `pre-reset-master` and recreate `master`
> as f31241ad6cb6474e559289f1bd7110ea5d5a4fba (
> https://github.com/apache/maven-integration-testing/commit/
> f31241ad6cb6474e559289f1bd7110ea5d5a4fba
> )
>
> 3. In git://git.apache.org/maven-resolver.git we will rename the current
> master branch to `pre-reset-master` and recreate `master`
> as b74f7a1e8837875b4780199f644119f55d22465d (
> https://github.com/apache/maven-resolver/commit/
> b74f7a1e8837875b4780199f644119f55d22465d),
> i.e. the 1.0.x branch
>
> We will then proceed to have (ideally) the original committers cherry-pick
> (and tidy up an squash... if the original committers are not able to assist
> then squashing may not be practicable) those changes that have been agreed
> for 3.5.0 as summarized on the
> https://cwiki.apache.org/confluence/display/MAVEN/Roadmap+2017 wiki page
> (authorative source of the decisions summarized in the wiki page is the
> mail thread:
> https://mail-archives.apache.org/mod_mbox/maven-dev/201612.mbox/%3CCA%
> 2BnPnMxERdjJq5ChMNP-HN_AvZOs8sm7Ud5aVcEza0BPnm5ZOw%40mail.gmail.com%3E
>  ).
>
> As this involves a --force push on the `master` branch, we want to get the
> approval of the committers before continuing.
>
> The vote will be open for at least 72 hours.
>
> The vote will be decided by a simple majority of valid votes cast. There is
> no veto.
>
> The vote is open to all committers.
>
> In addition, for the vote to be valid, there must be at least 3x+1 votes
> from PMC members
>
> [ ] +1: Yes
> [ ] 0:
> [ ] -1: No
>
> -Stephen
> --
> Sent from my phone
>



-- 
Cheers
Tibor

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

[Christian Schulte]

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
{
  System.exit();
}
finally
{
  // This will never be called. Correct.
}


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

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

[Christian Schulte]

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. That's the purpose of setting the resource to
null. The only intention there is a finally block is to clean up on
failure to not leak open resources *on failure*.

> 
> *ConsoleOutputFileReporter.java is missing flush at L69 because of
> FileOutputStream.close() which does not implicitly flush.*

No need to flush there as well because there is nothing to flush.
FileOutputStream does not perform any buffering. This is the Javadoc of
the java.io.Flushable interface:

"Flushes this stream by writing any buffered output to the underlying
stream."

If there is no buffer, flush becomes a no-op.

> 
> I disagree about relying on implicit flushing in every IO implementation.

You need to rely on the classes in the java.io package or you need to
roll your own.

> *PrintStream and BufferedWriter should make flush on close.PrintWrite and
> FileOutputStream do not flush on close.*

Because they do not perform any buffering. Take a look at the close and
flush methods in class OutputStream. They are no-ops when not
overridden. FileOutputStream does not override flush and inherits it as
a no-op because there is no buffer to flush. PrintStream does call flush
on close by calling close on the delegate. We really are discussing Java
fundamentals already.

> 
> In case of *PrintStream *and *BufferedWriter *it is however written in
> Javadoc that close() is done by flushing as well but it is not implemented
> in such way. 

Of course it is. If not, create a reproducible test case and report a
bug against the JDK.


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

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

[Tibor Digana]

>>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
exception before the finally block.
This is guarantee that whatever I place between try {...} , e.g
*return *or *throw
*exception except for System.exit or Runtime.halt, I have 100% guarantee
that finally block is executed anyway.
If I place close() in finally, everything is okay. That's why Java 7
feature "try-with-resources" compiles Java 7 code to using finally in
bytecode however it does not exist in source code.




On Sun, Jan 8, 2017 at 3:49 AM, Christian Schulte [via Maven] <
ml-node+s40175n5891905...@n5.nabble.com> wrote:

> 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();
> resource.close();
>
> 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.
> There seems to be one case for which an IT is failing now. The IT is
> forcing an OutOfMemoryError and due to missing flush calls, some file is
> empty or not even created at all, because that error isn't handled
> correctly (there somewhere is a missing finally block to ensure open
> resources are cleaned up correctly). No flush -> OutOfMemoryError -> no
> call to close anywhere so no flushes performed.
>
>
> -
> To unsubscribe, e-mail: [hidden email]
> 
> For additional commands, e-mail: [hidden email]
> 
>
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://maven.40175.n5.nabble.com/Lets-talk-about-our-
> changes-openly-maven-surefire-git-commit-SUREFIRE-1324-
> Surefire-incorrectly-supp-tp5891058p5891905.html
> To start a new topic under Maven Developers, email
> ml-node+s40175n142166...@n5.nabble.com
> To unsubscribe from Maven Developers, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://maven.40175.n5.nabble.com/Lets-talk-about-our-changes-openly-maven-surefire-git-commit-SUREFIRE-1324-Surefire-incorrectly-supp-tp5891058p5891931.html
Sent from the Maven Developers mailing list archive at Nabble.com.

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

[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.

*ConsoleOutputFileReporter.java is missing flush at L69 because of
FileOutputStream.close() which does not implicitly flush.*

I disagree about relying on implicit flushing in every IO implementation.
Flush is not called within every close() method of every I/O
implementation. I checked the JRE implementation and Javadoc.
About which Java class are you talking about?
According to the Javadoc (*implementation might be buggy*):

*PrintStream and BufferedWriter should make flush on close.PrintWrite and
FileOutputStream do not flush on close.*

In case of *PrintStream *and *BufferedWriter *it is however written in
Javadoc that close() is done by flushing as well but it is not implemented
in such way. Therefore I would not rely on it, and because of different
bugs in JRE between vendors I would not rely either.
As a real example of maybe JRE bug:
*PrintStream#close()*
calls
*BufferedWriter#close()*
which calls internal method
*flushBuffer()* but the problem is that this internal method *flushBuffer()*
does not flush the delegate stream
and the Javadoc says interesting things (*without** flushing the stream
itself*):
(it is writing char[] buffer to delegate stream, which is what Oracle means
a kind of flush, but not flushing in real)

/**
 * Flushes the output buffer to the underlying character stream,
*without** * flushing the stream itself*.  This method is non-private
only so that it
 * may be invoked by PrintStream.
 */
void flushBuffer() throws IOException {
synchronized (lock) {
ensureOpen();
if (nextChar == 0)
return;
*out.write(cb, 0, nextChar);*
nextChar = 0;
}
}

/**
 * Flushes the stream.
 *
 * @exception  IOException  If an I/O error occurs
 */
public void flush() throws IOException {
synchronized (lock) {
flushBuffer();
*out.flush();*
}
}













On Sun, Jan 8, 2017 at 3:49 AM, Christian Schulte [via Maven] <
ml-node+s40175n5891905...@n5.nabble.com> wrote:

> 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();
> resource.close();
>
> 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.
> There seems to be one case for which an IT is failing now. The IT is
> forcing an OutOfMemoryError and due to missing flush calls, some file is
> empty or not even created at all, because that error isn't handled
> correctly (there somewhere is a missing finally block to ensure open
> resources are cleaned up correctly). No flush -> OutOfMemoryError -> no
> call to close anywhere so no flushes performed.
>
>
> -
> To unsubscribe, e-mail: [hidden email]
> 
> For additional commands, e-mail: [hidden email]
> 
>
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://maven.40175.n5.nabble.com/Lets-talk-about-our-
> changes-openly-maven-surefire-git-commit-SUREFIRE-1324-
> Surefire-incorrectly-supp-tp5891058p5891905.html
> To start a new topic under Maven Developers, email
> ml-node+s40175n142166...@n5.nabble.com
> To unsubscribe from Maven Developers, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://maven.40175.n5.nabble.com/Lets-talk-about-our-changes-openly-maven-surefire-git-commit-SUREFIRE-1324-Surefire-incorrectly-supp-tp5891058p5891924.html
Sent from the Maven Developers mailing list archive at Nabble.com.

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

[Christian Schulte]

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, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

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

[Christian Schulte]

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 put()/take().
> 
> 
> public void consumeLine( String s )
> {
> items.add( s );
> if ( items.size() > ITEM_LIMIT_BEFORE_SLEEP )
> {
> try
> {
> Thread.sleep( 100 );
> }
> catch ( InterruptedException ignore )
> {
> }
> }
> }

If you already found the issue, just commit it. I just created



which may have an impact on
'org.apache.maven.plugin.surefire.report.StatelessXmlReporter' using it.
Will take a look at it tomorrow and see what can be done about it in the
shared utils. Turns out lack of PrintWriter/PrintStream checkError calls
became just another item on my ever growing list of pitfalls you can run
into. I wonder if Findbugs would have warned about it. If things like
this appear in some shared utility, a lot of things may be impacted by
it without noticing due to silently discarding exceptions.


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

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

[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 put()/take().


public void consumeLine( String s )
{
items.add( s );
if ( items.size() > ITEM_LIMIT_BEFORE_SLEEP )
{
try
{
Thread.sleep( 100 );
}
catch ( InterruptedException ignore )
{
}
}
}

On Sun, Jan 8, 2017 at 3:48 AM, Christian Schulte  wrote:

> 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();
> resource.close();
>
> 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.
> There seems to be one case for which an IT is failing now. The IT is
> forcing an OutOfMemoryError and due to missing flush calls, some file is
> empty or not even created at all, because that error isn't handled
> correctly (there somewhere is a missing finally block to ensure open
> resources are cleaned up correctly). No flush -> OutOfMemoryError -> no
> call to close anywhere so no flushes performed.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
Cheers
Tibor

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

[Christian Schulte]

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();
resource.close();

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.
There seems to be one case for which an IT is failing now. The IT is
forcing an OutOfMemoryError and due to missing flush calls, some file is
empty or not even created at all, because that error isn't handled
correctly (there somewhere is a missing finally block to ensure open
resources are cleaned up correctly). No flush -> OutOfMemoryError -> no
call to close anywhere so no flushes performed.


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

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

[Christian Schulte]

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
succeeded to the final statement (reader = null) because there has been
an exception. So the IOUtils.close(reader) only performs a real close
call, if there already has been an exception in the try block. That
exception is what needs to propagate. That's the reason the IOUtil.close
method just ignores any exception. It's misused nearly everyhwere.

> IOUtils.close(reader);
> }
> I know that IOUtils swallows exception on close().
> I agree that better would be
> 
> method () throws IOException
> 
> }
> finally
> {
> reader.close();
> }

The 'finally' clause is just there to clean up any resources when the
try block has thrown an exception. So the exception to propagate is the
one from the try block. If the exception from the finally block is
propagated, the causing exception from the try block disappears. You get
a stacktrace about a failing close on a resource which produced an
exception on usage you cannot see anywhere. So for the example above,
the close call in the finally block also is executed when there has been
an exception in the try block. It's most likely that the resource
failing in the try block will again fail in the finally block. That will
propagate the exception from the finally clause but not the original
exception from the try block. So maybe the try block would produce an
IOException with "Permission denied" you never see because you get an
IOException with "Close failed" hard to track to the original failure.

> Most probably read/write operation would fail on before closing the stream,
> but I would rather not to use IOUtil.close() since it swallows the
> exception.

It's just a static utility method to prevent you from having to write:

finally
{
  try
  {
if(resource != null)
{
  resource.close();
}
  }
  catch(IOException e)
  {
// Suppressed.
  }
}

The resource != null check is the important thing and setting it to null
as the last statement in the try block to indicate successful
completion. That's why I stopped using all kinds of WhateverUtil.close
and instead write it as shown above. I will now write that comment like
"Suppressed, so that the exception thrown in the try block will be
propagated." instead of just "Suppressed." in the future to make it even
clearer the exception needs to be ignored.

> 
> In case of PrintWriter it was just more simple to use it because of not
> needed additional three objects:
> FileOutputStream
> OutputStreamWriter
> BufferedWriter
> 
> I still do not understand why Oracle does not have IOException in method
> signatures of PrintWriter but hopefully they introduced checkError().
> For user it does not matter if the exception was originated from write() or
> synthetic one. The important is that the plugin fails on fatal error
> without hanging and with meaningful message.
> I think we can do both:
> + compact code
> + IOException as well
> We can add our utility class which closes PrintWriter, calls checkError()
> and throws IOException. WDYT?

I am just heading for not ignoring any exceptions thrown silently. It's
that what makes it hard to find out about issues you could easily spot
if you have a stacktrace instead of - well - nothing but some unexpected
behaviour.



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

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

[Tibor Digana]

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 3:28 AM, Tibor Digana  wrote:

> 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 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
> > 
> > }
> > finally
> > {
> > reader.close();
> > }
> > Most probably read/write operation would fail on before closing the
> > stream,
> > but I would rather not to use IOUtil.close() since it swallows the
> > exception.
> >
> > In case of PrintWriter it was just more simple to use it because of not
> > needed additional three objects:
> > FileOutputStream
> > OutputStreamWriter
> > BufferedWriter
> >
> > I still do not understand why Oracle does not have IOException in method
> > signatures of PrintWriter but hopefully they introduced checkError().
> > For user it does not matter if the exception was originated from write()
> > or
> > synthetic one. The important is that the plugin fails on fatal error
> > without hanging and with meaningful message.
> > I think we can do both:
> > + compact code
> > + IOException as well
> > We can add our utility class which closes PrintWriter, calls checkError()
> > and throws IOException. WDYT?
> >
> >
> >
> >
> >
> >
> >
> > On Sun, Jan 8, 2017 at 2:43 AM, Christian Schulte <[hidden email]
> > > wrote:
> >
> > > 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 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.
> > >
> > > Have you read the Javadoc of the 'closeQuietly' methods as I suggested?
> > >  > > api-release/org/apache/commons/io/IOUtils.html>
> > >
> > > Looking at the commits, I get the impression, you haven't got the point
> > > in closing resources on failure and again added things suppressing
> > > exceptions not to ignore.
> > >
> > > > Except for PrintWriter there is again all old staff back like missed
> > > > flush(), etc.
> > >
> > > There are no missing flush calls. Where?
> > >
> > > > Btw. PrintWriter has a method which could be called and throw
> > exception
> > > > from our code
> > >
> > > Why use the PrintWriter class in some private method if you must add
> > > special exception handling to it when you could just use a writer with
> > > standard exception handling? That's been my intention. I am still
> > > running the ITs locally. Will take a look if things don't succeed.
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: [hidden email]
> > 
> > > For additional commands, e-mail: [hidden email]
> > 
> > >
> > >
> >
> >
> > --
> > Cheers
> > Tibor
> >
> >
> > --
> > If you reply to this email, your message will be added to the discussion
> > below:
> > http://maven.40175.n5.nabble.com/Lets-talk-about-our-
> > changes-openly-maven-surefire-git-commit-SUREFIRE-1324-
> > Surefire-incorrectly-supp-tp5891058p5891886.html
> > To start a new topic under Maven Developers, email
> > ml-node+s40175n142166...@n5.nabble.com
> > To unsubscribe from Maven Developers, click here
> >  macro=unsubscribe_by_code=142166=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3
> wxNDIxNjZ8LTI4OTQ5MjEwMg==>
> > .
> > NAML
> >  macro=macro_viewer=instant_html%21nabble%3Aemail.naml&
> base=nabble.naml.namespaces.BasicNamespace-nabble.view.
> web.template.NabbleNamespace-nabble.view.web.template.
> NodeNamespace=notify_subscribers%21nabble%
> 3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_
> instant_email%21nabble%3Aemail.naml>
> >
>
>
>
>
> --
> View this message in context: 

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

[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.

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 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
> 
> }
> finally
> {
> reader.close();
> }
> Most probably read/write operation would fail on before closing the
> stream,
> but I would rather not to use IOUtil.close() since it swallows the
> exception.
>
> In case of PrintWriter it was just more simple to use it because of not
> needed additional three objects:
> FileOutputStream
> OutputStreamWriter
> BufferedWriter
>
> I still do not understand why Oracle does not have IOException in method
> signatures of PrintWriter but hopefully they introduced checkError().
> For user it does not matter if the exception was originated from write()
> or
> synthetic one. The important is that the plugin fails on fatal error
> without hanging and with meaningful message.
> I think we can do both:
> + compact code
> + IOException as well
> We can add our utility class which closes PrintWriter, calls checkError()
> and throws IOException. WDYT?
>
>
>
>
>
>
>
> On Sun, Jan 8, 2017 at 2:43 AM, Christian Schulte <[hidden email]
> > wrote:
>
> > 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 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.
> >
> > Have you read the Javadoc of the 'closeQuietly' methods as I suggested?
> >  > api-release/org/apache/commons/io/IOUtils.html>
> >
> > Looking at the commits, I get the impression, you haven't got the point
> > in closing resources on failure and again added things suppressing
> > exceptions not to ignore.
> >
> > > Except for PrintWriter there is again all old staff back like missed
> > > flush(), etc.
> >
> > There are no missing flush calls. Where?
> >
> > > Btw. PrintWriter has a method which could be called and throw
> exception
> > > from our code
> >
> > Why use the PrintWriter class in some private method if you must add
> > special exception handling to it when you could just use a writer with
> > standard exception handling? That's been my intention. I am still
> > running the ITs locally. Will take a look if things don't succeed.
> >
> >
> > -
> > To unsubscribe, e-mail: [hidden email]
> 
> > For additional commands, e-mail: [hidden email]
> 
> >
> >
>
>
> --
> Cheers
> Tibor
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://maven.40175.n5.nabble.com/Lets-talk-about-our-
> changes-openly-maven-surefire-git-commit-SUREFIRE-1324-
> Surefire-incorrectly-supp-tp5891058p5891886.html
> To start a new topic under Maven Developers, email
> ml-node+s40175n142166...@n5.nabble.com
> To unsubscribe from Maven Developers, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://maven.40175.n5.nabble.com/Lets-talk-about-our-changes-openly-maven-surefire-git-commit-SUREFIRE-1324-Surefire-incorrectly-supp-tp5891058p5891890.html
Sent from the Maven Developers mailing list archive at Nabble.com.

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

[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 {
IOUtils.close(reader);
}
I know that IOUtils swallows exception on close().
I agree that better would be

method () throws IOException

}
finally
{
reader.close();
}
Most probably read/write operation would fail on before closing the stream,
but I would rather not to use IOUtil.close() since it swallows the
exception.

In case of PrintWriter it was just more simple to use it because of not
needed additional three objects:
FileOutputStream
OutputStreamWriter
BufferedWriter

I still do not understand why Oracle does not have IOException in method
signatures of PrintWriter but hopefully they introduced checkError().
For user it does not matter if the exception was originated from write() or
synthetic one. The important is that the plugin fails on fatal error
without hanging and with meaningful message.
I think we can do both:
+ compact code
+ IOException as well
We can add our utility class which closes PrintWriter, calls checkError()
and throws IOException. WDYT?







On Sun, Jan 8, 2017 at 2:43 AM, Christian Schulte  wrote:

> 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 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.
>
> Have you read the Javadoc of the 'closeQuietly' methods as I suggested?
>  api-release/org/apache/commons/io/IOUtils.html>
>
> Looking at the commits, I get the impression, you haven't got the point
> in closing resources on failure and again added things suppressing
> exceptions not to ignore.
>
> > Except for PrintWriter there is again all old staff back like missed
> > flush(), etc.
>
> There are no missing flush calls. Where?
>
> > Btw. PrintWriter has a method which could be called and throw exception
> > from our code
>
> Why use the PrintWriter class in some private method if you must add
> special exception handling to it when you could just use a writer with
> standard exception handling? That's been my intention. I am still
> running the ITs locally. Will take a look if things don't succeed.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
Cheers
Tibor

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

[Christian Schulte]

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
> .
> 
>> 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.
> 
> Have you read the Javadoc of the 'closeQuietly' methods as I suggested?
> 
> 
> Looking at the commits, I get the impression, you haven't got the point
> in closing resources on failure and again added things suppressing
> exceptions not to ignore.
> 
>> Except for PrintWriter there is again all old staff back like missed
>> flush(), etc.
> 
> There are no missing flush calls. Where?

I really need to know about that. There may be missing close calls.
Allright. Those calls are really missing then or there will be resource
leaks all around.


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

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

[Christian Schulte]

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 had objections.

Yeah. Sorry about that. I missed that email. I am still catching up with
all those unread emails on dev@. I committed, waited for the commit mail
to arrive and then wanted to answer to the original thread about what I
did. I then noticed you responded there and answered immediately.

> Usually I am doing fresh clone from Git and I apply changes from a stash
> and I use to check every single line and then commit if ok, and git fetch
> and rebase before push. I use to check GitHub commits before this procedure.

I do review things line by line before commit. I just wasn't aware that
there have been merges with changes "gitk" did not show or I maybe just
did not notice how to make those appear in "gitk".


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

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

[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 had objections.

Usually I am doing fresh clone from Git and I apply changes from a stash
and I use to check every single line and then commit if ok, and git fetch
and rebase before push. I use to check GitHub commits before this procedure.


On Sun, Jan 8, 2017 at 2:33 AM, Christian Schulte  wrote:

> 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 been way smarter to just "git revert" the commit in question.
>
> >
> > Whether you take the advice, or not, this is how I ensure that my changes
> > are clean and focused and coherent, every time.
>
> I assume "git pull" to not create any conflicts locally if the branch I
> am pulling into is what has been pushed. It's the commit to master
> having blown up things.
>
> >
> > Pull is a blind operation, which basically says "get whatever is out
> there,
> > even though I have no idea what it is, and try to merge my changes with
> > those changes, regardless, and before reviewing what those changes are".
>
> I had no local changes and I was suprised a "git pull" creates local
> conflicts because someone exchanged master with his personal/feature
> branch and force pushed that. Those pushes should not even be possible.
>
> > If you fetch first you can at least look and make a conscious decision.
> Not
> > possible if you pull.
> >
> > This style fits with the Apache "just commit it" mentality, but relies on
> > individual developer discipline to work well. The task of "gate keeper"
> is
> > effectively distributed to each person wanting to push; they gate keep
> > themselves, or not.
> >
> > Fred.
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
Cheers
Tibor

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

[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
.

> 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.

Have you read the Javadoc of the 'closeQuietly' methods as I suggested?


Looking at the commits, I get the impression, you haven't got the point
in closing resources on failure and again added things suppressing
exceptions not to ignore.

> Except for PrintWriter there is again all old staff back like missed
> flush(), etc.

There are no missing flush calls. Where?

> Btw. PrintWriter has a method which could be called and throw exception
> from our code

Why use the PrintWriter class in some private method if you must add
special exception handling to it when you could just use a writer with
standard exception handling? That's been my intention. I am still
running the ITs locally. Will take a look if things don't succeed.


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

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

[Tibor17]

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 Sun, Jan 8, 2017 at 12:33 AM, Marcin Zajączkowski <
notificati...@github.com> wrote:

> @Tibor17  Is there something else that
> prevent that PR from being merged?
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> 
,
> or mute the thread
> 

> .
>



-- 
Cheers
Tibor



---
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 feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

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

[Christian Schulte]

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 been way smarter to just "git revert" the commit in question.

> 
> Whether you take the advice, or not, this is how I ensure that my changes
> are clean and focused and coherent, every time.

I assume "git pull" to not create any conflicts locally if the branch I
am pulling into is what has been pushed. It's the commit to master
having blown up things.

> 
> Pull is a blind operation, which basically says "get whatever is out there,
> even though I have no idea what it is, and try to merge my changes with
> those changes, regardless, and before reviewing what those changes are".

I had no local changes and I was suprised a "git pull" creates local
conflicts because someone exchanged master with his personal/feature
branch and force pushed that. Those pushes should not even be possible.

> If you fetch first you can at least look and make a conscious decision. Not
> possible if you pull.
> 
> This style fits with the Apache "just commit it" mentality, but relies on
> individual developer discipline to work well. The task of "gate keeper" is
> effectively distributed to each person wanting to push; they gate keep
> themselves, or not.
> 
> Fred.



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

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

[Tibor Digana]

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
> 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 blind operation, which basically says "get whatever is out
> there,
> even though I have no idea what it is, and try to merge my changes with
> those changes, regardless, and before reviewing what those changes are".
>
> If you fetch first you can at least look and make a conscious decision.
> Not
> possible if you pull.
>
> This style fits with the Apache "just commit it" mentality, but relies on
> individual developer discipline to work well. The task of "gate keeper" is
> effectively distributed to each person wanting to push; they gate keep
> themselves, or not.
>
> Fred.
>
>
> On Sun, Jan 8, 2017 at 1:27 PM, Tibor Digana <[hidden email]
> >
> wrote:
>
> > 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 there is again all old staff back like missed
> > flush(), etc.
> > Btw. PrintWriter has a method which could be called and throw exception
> > from our code
> >
> > public boolean checkError() {
> > if (out != null) {
> > flush();
> > }
> > if (out instanceof java.io.PrintWriter) {
> > PrintWriter pw = (PrintWriter) out;
> > return pw.checkError();
> > } else if (psOut != null) {
> > return psOut.checkError();
> > }
> > return trouble;
> > }
> >
> >
> >
> >
> > On Sun, Jan 8, 2017 at 12:47 AM, Christian Schulte <[hidden email]
> >
> > wrote:
> >
> > > 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 emails. Could be I just made that?  I
> "git
> > > pull"ed and that produced conflicts. I solved those conflicts and then
> > > pushed. Your changes are preserved, of course.
> > >
> > > I changed usages of "PrintWriter" to a "real" writer where possible
> > > (only used privately) because the PrintWriter does not throw any
> > > IOException and all "checkError" calls where missing.
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: [hidden email]
> 
> > > For additional commands, e-mail: [hidden email]
> 
> > >
> > >
> >
> >
> > --
> > Cheers
> > Tibor
> >
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://maven.40175.n5.nabble.com/Lets-talk-about-our-
> changes-openly-maven-surefire-git-commit-SUREFIRE-1324-
> Surefire-incorrectly-supp-tp5891058p5891853.html
> To start a new topic under Maven Developers, email
> ml-node+s40175n142166...@n5.nabble.com
> To unsubscribe from Maven Developers, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://maven.40175.n5.nabble.com/Lets-talk-about-our-changes-openly-maven-surefire-git-commit-SUREFIRE-1324-Surefire-incorrectly-supp-tp5891058p5891858.html
Sent from the Maven Developers mailing list archive at Nabble.com.

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

[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.

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 blind operation, which basically says "get whatever is out there,
even though I have no idea what it is, and try to merge my changes with
those changes, regardless, and before reviewing what those changes are".

If you fetch first you can at least look and make a conscious decision. Not
possible if you pull.

This style fits with the Apache "just commit it" mentality, but relies on
individual developer discipline to work well. The task of "gate keeper" is
effectively distributed to each person wanting to push; they gate keep
themselves, or not.

Fred.


On Sun, Jan 8, 2017 at 1:27 PM, Tibor Digana 
wrote:

> 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 there is again all old staff back like missed
> flush(), etc.
> Btw. PrintWriter has a method which could be called and throw exception
> from our code
>
> public boolean checkError() {
> if (out != null) {
> flush();
> }
> if (out instanceof java.io.PrintWriter) {
> PrintWriter pw = (PrintWriter) out;
> return pw.checkError();
> } else if (psOut != null) {
> return psOut.checkError();
> }
> return trouble;
> }
>
>
>
>
> On Sun, Jan 8, 2017 at 12:47 AM, Christian Schulte 
> wrote:
>
> > 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 emails. Could be I just made that?  I "git
> > pull"ed and that produced conflicts. I solved those conflicts and then
> > pushed. Your changes are preserved, of course.
> >
> > I changed usages of "PrintWriter" to a "real" writer where possible
> > (only used privately) because the PrintWriter does not throw any
> > IOException and all "checkError" calls where missing.
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
>
> --
> Cheers
> Tibor
>

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

[Tibor Digana]

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 there is again all old staff back like missed
flush(), etc.
Btw. PrintWriter has a method which could be called and throw exception
from our code

public boolean checkError() {
if (out != null) {
flush();
}
if (out instanceof java.io.PrintWriter) {
PrintWriter pw = (PrintWriter) out;
return pw.checkError();
} else if (psOut != null) {
return psOut.checkError();
}
return trouble;
}




On Sun, Jan 8, 2017 at 12:47 AM, Christian Schulte 
wrote:

> 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 emails. Could be I just made that?  I "git
> pull"ed and that produced conflicts. I solved those conflicts and then
> pushed. Your changes are preserved, of course.
>
> I changed usages of "PrintWriter" to a "real" writer where possible
> (only used privately) because the PrintWriter does not throw any
> IOException and all "checkError" calls where missing.
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
Cheers
Tibor

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

[Christian Schulte]

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 emails. Could be I just made that?  I "git
pull"ed and that produced conflicts. I solved those conflicts and then
pushed. Your changes are preserved, of course.

I changed usages of "PrintWriter" to a "real" writer where possible
(only used privately) because the PrintWriter does not throw any
IOException and all "checkError" calls where missing.



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

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

[szpak]

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 project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

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

[Tibor17]

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 feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

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

[Stephen Connolly]

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 consist of an
> effective no-op change of Eclipse's Aether for the code after migration to
> Apache's Maven Resolver plus some other orthogonal changes around logging
> colourization and launcher script bug fixes.
>
> Given that some developer private builds of the current master branch have
> been shared with as 3.4.0-SNAPSHOT. More critically, JIRA issues have been
> closed with a fixed version of 3.4.0.
>
> For us to release a 3.4.0 with those fixes reverted, could cause confusion
> with our user community.
>
> Additionally the informal practice of keeping existing integration tests
> as RTC has not been followed, leading to some people to question whether
> the integration tests remain valid.
>
> For all the above reasons it is proposed to do *all* the following as an
> whole:
>
> 1. In git://git.apache.org/maven.git we will rename the current master
> branch to `pre-reset-master` and recreate `master` as
> bce33aa2662a51d18cb00347cf2fb174dc195fb1 (https://github.com/apache/
> maven/commit/bce33aa2662a51d18cb00347cf2fb174dc195fb1)
>
> 2. In git://git.apache.org/maven-integration-testing.git we will rename
> the current master branch to `pre-reset-master` and recreate `master` as
> f31241ad6cb6474e559289f1bd7110ea5d5a4fba (https://github.com/apache/
> maven-integration-testing/commit/f31241ad6cb6474e559289f1bd7110ea5d5a4fba)
>
> 3. In git://git.apache.org/maven-resolver.git we will rename the current
> master branch to `pre-reset-master` and recreate `master` as
> b74f7a1e8837875b4780199f644119f55d22465d (https://github.com/apache/
> maven-resolver/commit/b74f7a1e8837875b4780199f644119f55d22465d), i.e. the
> 1.0.x branch
>
> We will then proceed to have (ideally) the original committers cherry-pick
> (and tidy up an squash... if the original committers are not able to assist
> then squashing may not be practicable) those changes that have been agreed
> for 3.5.0 as summarized on the https://cwiki.apache.org/
> confluence/display/MAVEN/Roadmap+2017 wiki page (authorative source of
> the decisions summarized in the wiki page is the mail thread:
> https://mail-archives.apache.org/mod_mbox/maven-dev/201612.mbox/%3CCA%
> 2BnPnMxERdjJq5ChMNP-HN_AvZOs8sm7Ud5aVcEza0BPnm5ZOw%40mail.gmail.com%3E ).
>
> As this involves a --force push on the `master` branch, we want to get the
> approval of the committers before continuing.
>
> The vote will be open for at least 72 hours.
>
> The vote will be decided by a simple majority of valid votes cast. There
> is no veto.
>
> The vote is open to all committers.
>
> In addition, for the vote to be valid, there must be at least 3x+1 votes
> from PMC members
>
> [ ] +1: Yes
> [ ] 0:
> [ ] -1: No
>
> -Stephen
> --
> Sent from my phone
>

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

[Tibor17]

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 appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org