subject:"I think we are ready for 3.5.0\-alpha\-1"

Am 2017-02-14 um 21:52 schrieb Karl Heinz Marbaise:

Hi Michael,

On 14/02/17 21:47, Michael Osipov wrote:

Am 2017-02-14 um 21:23 schrieb Karl Heinz Marbaise:

Hi,

so this looks like the problem is fixed..and maven-clean-plugin is not
the culprit ...

This isn't related. Surefire722 fails with 3.0.0, but works with MCLEAN
2.6.1. I can provide log files if you want.

Would be nice to provide a log...so I can take a look into it...

Here you go:
http://home.apache.org/~michaelo/maven/surefire/MCLEAN-3.0.0-bug/maven-surefire-MCLEAN.tar.gz

Two successful runs, one fails with MNG-6169 and MCLEAN 3.0.0. Target
directory of surefire-integration-tests is included.

On 14/02/17 15:31, Michael Osipov wrote:

This test passes flawlessly.

Hi Michael,

If you will run the build again, this test should not fail. At least
I hope
so, because it's ok on my side
https://builds.apache.org/job/maven-surefire/org.apache.maven.surefire$surefire-integration-tests/1673/testReport/junit/org.apache.maven.surefire.its/ConsoleOutputIT/largerSoutThanMemory/

I will check Jenkins build result tomorrow morning.

On Mon, Feb 13, 2017 at 10:47 PM, Michael Osipov-2 [via Maven] <
ml-node+s40175n589856...@n5.nabble.com> wrote:

Am 2017-02-13 um 21:36 schrieb Tibor Digana:

I am working with Michael on FreeBSD issues.
I will try to fix one IT today and I will analyse the logs with
next two
ITs.
Did we change something regarding SITE in Maven 3.5.0-SNAPSHOT ?

I was able to tackle the constant failure of
Surefire772NoSurefireReportsIT on FreeBSD. Maven from master works,
but
fails from MNG-6169. The root cause is the ugprade of the Clean
Plugin
to 3.0.0. 2.6.1 works flawlessly, 3.0.1-SNAPSHOT fails too. I
consider
the Clean Plugin broken is some way.

@Karl Heinz, do you think yo could assist in finding the bug?

I will continue with the other failures on FreeBSD, Maven from master
and Surefire from master.

Michael

On Mon, Feb 13, 2017 at 6:32 PM, Tibor Digana-2 [via Maven] <
[hidden email]
>

wrote:

The HEAD in Surefire has a Jira fix 1322 which is using the same IT

which

failed on FreeBSD. So I simply included FreeBSD fix in the test
Surefire141PluggableProvidersIT.
I hope you will be happy with that.
The only last IT which fails and I did not have time to
investigate is
Surefire772NoSurefireReportsIT. This is from your log you sent me:

testOptionalSurefireReportGeneration(org.apache.maven.surefire.its.jiras.

Surefire772NoSurefireReportsIT)
Time elapsed: 0 sec <<< FAILURE!
java.lang.AssertionError: Expecting failsafe report file
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at
org.apache.maven.surefire.its.jiras.Surefire772NoSurefireReportsIT.
testOptionalSurefireReportGeneration(Surefire772NoSurefireReportsIT.java:75)

On Mon, Feb 13, 2017 at 4:49 PM, Michael Osipov <[hidden email]
> wrote:

I am currently running a patched version of Maven with the
offensive
commit reverted against Surefire master on FreeBSD 10.3-STABLE.
I'll

see

wether this is the cause in an hour or so.

Michael

I’ve logged the change in precedence as
https://issues.apache.org/

jira/browse/MNG-6172 since this has the potential to break CI
builds
which relied on the previous last-one-wins behaviour

On Monday, 13 February 2017 at 06:54, Tibor Digana wrote:

Exactly this is the problem - forkMode and reuseForks in one

function.

I will open Jira and push a fix.

On Mon, Feb 13, 2017 at 2:44 AM, Stuart McCulloch [via Maven] <
[hidden email]

(mailto:

ml-node+

[hidden email]
)>

wrote:

So I tweaked ForkedLauncher from maven-verifier to dump out the

forked

command to log.txt and at least one of the failing ITs has a

duplicated

system property on the command-line:

mvn -e --batch-mode -Dmaven.repo.local=/tmp/maven-
surefire/surefire-integration-tests/../surefire-setup-
integration-tests/target/it-repo org.apache.maven.plugins:

maven-clean-plugin:clean

-Dsurefire.version=2.19.2-SNAPSHOT -DtestNgVersion=5.7
-DtestNgClassifier=jdk15 -DforkMode=perthread
-DreuseForks=false
-DreuseForks=true -DthreadCount=1 -DtestProperty=testValue_${
surefire.threadNumber}_${surefire.forkNumber}

org.apache.maven.plugins.

surefire:maven-dump-pid-plugin:dump-pid test

specifically:

-DreuseForks=false -DreuseForks=true

Looking at SurefireLauncher.java

https://github.com/apache/maven-surefire/blob/master/
surefire-integration-tests/src/test/java/org/apache/
maven/surefire/its/fixture/SurefireLauncher.java

1. the reuseForks method adds a new system property argument
each

time

it’s called: -DreuseForks=
2. the forkPerThread method calls forkMode( "perthread"

).reuseForks(

false )
3. the forkOncePerThread calls forkPerThread().reuseForks(
true )

So any test using SurefireLauncher’s

Re: I think we are ready for 3.5.0-alpha-1

2017-02-14 Thread Karl Heinz Marbaise

Hi Michael,

On 14/02/17 21:47, Michael Osipov wrote:

Am 2017-02-14 um 21:23 schrieb Karl Heinz Marbaise:

Hi,

so this looks like the problem is fixed..and maven-clean-plugin is not
the culprit ...

This isn't related. Surefire722 fails with 3.0.0, but works with MCLEAN
2.6.1. I can provide log files if you want.

Would be nice to provide a log...so I can take a look into it...

Kind regards
Karl Heinz

On 14/02/17 15:31, Michael Osipov wrote:

This test passes flawlessly.

Hi Michael,

I will check Jenkins build result tomorrow morning.

On Mon, Feb 13, 2017 at 10:47 PM, Michael Osipov-2 [via Maven] <
ml-node+s40175n589856...@n5.nabble.com> wrote:

Am 2017-02-13 um 21:36 schrieb Tibor Digana:

I am working with Michael on FreeBSD issues.
I will try to fix one IT today and I will analyse the logs with
next two
ITs.
Did we change something regarding SITE in Maven 3.5.0-SNAPSHOT ?

I was able to tackle the constant failure of
Surefire772NoSurefireReportsIT on FreeBSD. Maven from master works,
but
fails from MNG-6169. The root cause is the ugprade of the Clean Plugin
to 3.0.0. 2.6.1 works flawlessly, 3.0.1-SNAPSHOT fails too. I consider
the Clean Plugin broken is some way.

@Karl Heinz, do you think yo could assist in finding the bug?

I will continue with the other failures on FreeBSD, Maven from master
and Surefire from master.

Michael

On Mon, Feb 13, 2017 at 6:32 PM, Tibor Digana-2 [via Maven] <
[hidden email]
>

wrote:

The HEAD in Surefire has a Jira fix 1322 which is using the same IT

which

testOptionalSurefireReportGeneration(org.apache.maven.surefire.its.jiras.

On Mon, Feb 13, 2017 at 4:49 PM, Michael Osipov <[hidden email]
> wrote:

I am currently running a patched version of Maven with the
offensive
commit reverted against Surefire master on FreeBSD 10.3-STABLE.
I'll

see

wether this is the cause in an hour or so.

Michael

I’ve logged the change in precedence as https://issues.apache.org/

jira/browse/MNG-6172 since this has the potential to break CI
builds
which relied on the previous last-one-wins behaviour

On Monday, 13 February 2017 at 06:54, Tibor Digana wrote:

Exactly this is the problem - forkMode and reuseForks in one

function.

I will open Jira and push a fix.

On Mon, Feb 13, 2017 at 2:44 AM, Stuart McCulloch [via Maven] <
[hidden email]

(mailto:

ml-node+

[hidden email]
)>

wrote:

So I tweaked ForkedLauncher from maven-verifier to dump out the

forked

command to log.txt and at least one of the failing ITs has a

duplicated

system property on the command-line:

mvn -e --batch-mode -Dmaven.repo.local=/tmp/maven-
surefire/surefire-integration-tests/../surefire-setup-
integration-tests/target/it-repo org.apache.maven.plugins:

maven-clean-plugin:clean

-Dsurefire.version=2.19.2-SNAPSHOT -DtestNgVersion=5.7
-DtestNgClassifier=jdk15 -DforkMode=perthread -DreuseForks=false
-DreuseForks=true -DthreadCount=1 -DtestProperty=testValue_${
surefire.threadNumber}_${surefire.forkNumber}

org.apache.maven.plugins.

surefire:maven-dump-pid-plugin:dump-pid test

specifically:

-DreuseForks=false -DreuseForks=true

Looking at SurefireLauncher.java

https://github.com/apache/maven-surefire/blob/master/
surefire-integration-tests/src/test/java/org/apache/
maven/surefire/its/fixture/SurefireLauncher.java

1. the reuseForks method adds a new system property argument
each

time

it’s called: -DreuseForks=
2. the forkPerThread method calls forkMode( "perthread"

).reuseForks(

false )
3. the forkOncePerThread calls forkPerThread().reuseForks(
true )

So any test using SurefireLauncher’s “forkOncePerThread” method

will

end

up with two “reuseForks” system property options on the

command-line

- and

will therefore be affected by the change in system property
option
precedence.

This explains why ForkModeIT fails for me locally with master,
but

Re: I think we are ready for 3.5.0-alpha-1

Am 2017-02-14 um 21:23 schrieb Karl Heinz Marbaise:

Hi,

so this looks like the problem is fixed..and maven-clean-plugin is not
the culprit ...

This isn't related. Surefire722 fails with 3.0.0, but works with MCLEAN
2.6.1. I can provide log files if you want.

On 14/02/17 15:31, Michael Osipov wrote:

This test passes flawlessly.

Hi Michael,

I will check Jenkins build result tomorrow morning.

On Mon, Feb 13, 2017 at 10:47 PM, Michael Osipov-2 [via Maven] <
ml-node+s40175n589856...@n5.nabble.com> wrote:

Am 2017-02-13 um 21:36 schrieb Tibor Digana:

I am working with Michael on FreeBSD issues.
I will try to fix one IT today and I will analyse the logs with
next two
ITs.
Did we change something regarding SITE in Maven 3.5.0-SNAPSHOT ?

I was able to tackle the constant failure of
Surefire772NoSurefireReportsIT on FreeBSD. Maven from master works, but
fails from MNG-6169. The root cause is the ugprade of the Clean Plugin
to 3.0.0. 2.6.1 works flawlessly, 3.0.1-SNAPSHOT fails too. I consider
the Clean Plugin broken is some way.

@Karl Heinz, do you think yo could assist in finding the bug?

I will continue with the other failures on FreeBSD, Maven from master
and Surefire from master.

Michael

On Mon, Feb 13, 2017 at 6:32 PM, Tibor Digana-2 [via Maven] <
[hidden email]
>

wrote:

The HEAD in Surefire has a Jira fix 1322 which is using the same IT

which

testOptionalSurefireReportGeneration(org.apache.maven.surefire.its.jiras.

On Mon, Feb 13, 2017 at 4:49 PM, Michael Osipov <[hidden email]
> wrote:

I am currently running a patched version of Maven with the offensive
commit reverted against Surefire master on FreeBSD 10.3-STABLE. I'll

see

wether this is the cause in an hour or so.

Michael

I’ve logged the change in precedence as https://issues.apache.org/

jira/browse/MNG-6172 since this has the potential to break CI builds
which relied on the previous last-one-wins behaviour

On Monday, 13 February 2017 at 06:54, Tibor Digana wrote:

Exactly this is the problem - forkMode and reuseForks in one

function.

I will open Jira and push a fix.

On Mon, Feb 13, 2017 at 2:44 AM, Stuart McCulloch [via Maven] <
[hidden email]

(mailto:

ml-node+

[hidden email]
)>

wrote:

So I tweaked ForkedLauncher from maven-verifier to dump out the

forked

command to log.txt and at least one of the failing ITs has a

duplicated

system property on the command-line:

mvn -e --batch-mode -Dmaven.repo.local=/tmp/maven-
surefire/surefire-integration-tests/../surefire-setup-
integration-tests/target/it-repo org.apache.maven.plugins:

maven-clean-plugin:clean

-Dsurefire.version=2.19.2-SNAPSHOT -DtestNgVersion=5.7
-DtestNgClassifier=jdk15 -DforkMode=perthread -DreuseForks=false
-DreuseForks=true -DthreadCount=1 -DtestProperty=testValue_${
surefire.threadNumber}_${surefire.forkNumber}

org.apache.maven.plugins.

surefire:maven-dump-pid-plugin:dump-pid test

specifically:

-DreuseForks=false -DreuseForks=true

Looking at SurefireLauncher.java

https://github.com/apache/maven-surefire/blob/master/
surefire-integration-tests/src/test/java/org/apache/
maven/surefire/its/fixture/SurefireLauncher.java

1. the reuseForks method adds a new system property argument each

time

it’s called: -DreuseForks=
2. the forkPerThread method calls forkMode( "perthread"

).reuseForks(

false )
3. the forkOncePerThread calls forkPerThread().reuseForks( true )

So any test using SurefireLauncher’s “forkOncePerThread” method

will

end

up with two “reuseForks” system property options on the

command-line

- and

will therefore be affected by the change in system property
option
precedence.

This explains why ForkModeIT fails for me locally with master,
but

passes

with 3.3.9 - with current master the -DreuseForks=false option

wins,

whereas with 3.3.9 the -DreuseForks=true options wins.

If I change

Re: I think we are ready for 3.5.0-alpha-1

2017-02-14 Thread Karl Heinz Marbaise

Hi,

so this looks like the problem is fixed..and maven-clean-plugin is not
the culprit ...

Kind regards
Karl Heinz Marbaise

On 14/02/17 15:31, Michael Osipov wrote:

This test passes flawlessly.

Hi Michael,

If you will run the build again, this test should not fail. At least I hope
so, because it's ok on my side
https://builds.apache.org/job/maven-surefire/org.apache.maven.surefire$surefire-integration-tests/1673/testReport/junit/org.apache.maven.surefire.its/ConsoleOutputIT/largerSoutThanMemory/
I will check Jenkins build result tomorrow morning.

On Mon, Feb 13, 2017 at 10:47 PM, Michael Osipov-2 [via Maven] <
ml-node+s40175n589856...@n5.nabble.com> wrote:

Am 2017-02-13 um 21:36 schrieb Tibor Digana:

I am working with Michael on FreeBSD issues.
I will try to fix one IT today and I will analyse the logs with next two
ITs.
Did we change something regarding SITE in Maven 3.5.0-SNAPSHOT ?

I was able to tackle the constant failure of
Surefire772NoSurefireReportsIT on FreeBSD. Maven from master works, but
fails from MNG-6169. The root cause is the ugprade of the Clean Plugin
to 3.0.0. 2.6.1 works flawlessly, 3.0.1-SNAPSHOT fails too. I consider
the Clean Plugin broken is some way.

@Karl Heinz, do you think yo could assist in finding the bug?

I will continue with the other failures on FreeBSD, Maven from master
and Surefire from master.

Michael

On Mon, Feb 13, 2017 at 6:32 PM, Tibor Digana-2 [via Maven] <
[hidden email] >

wrote:

The HEAD in Surefire has a Jira fix 1322 which is using the same IT

which

failed on FreeBSD. So I simply included FreeBSD fix in the test
Surefire141PluggableProvidersIT.
I hope you will be happy with that.
The only last IT which fails and I did not have time to investigate is
Surefire772NoSurefireReportsIT. This is from your log you sent me:

testOptionalSurefireReportGeneration(org.apache.maven.surefire.its.jiras.

On Mon, Feb 13, 2017 at 4:49 PM, Michael Osipov <[hidden email]
> wrote:

I am currently running a patched version of Maven with the offensive
commit reverted against Surefire master on FreeBSD 10.3-STABLE. I'll

see

wether this is the cause in an hour or so.

Michael

I’ve logged the change in precedence as https://issues.apache.org/

jira/browse/MNG-6172 since this has the potential to break CI builds
which relied on the previous last-one-wins behaviour

On Monday, 13 February 2017 at 06:54, Tibor Digana wrote:

Exactly this is the problem - forkMode and reuseForks in one

function.

I will open Jira and push a fix.

On Mon, Feb 13, 2017 at 2:44 AM, Stuart McCulloch [via Maven] <
[hidden email]

(mailto:

ml-node+

[hidden email] )>

wrote:

So I tweaked ForkedLauncher from maven-verifier to dump out the

forked

command to log.txt and at least one of the failing ITs has a

duplicated

system property on the command-line:

mvn -e --batch-mode -Dmaven.repo.local=/tmp/maven-
surefire/surefire-integration-tests/../surefire-setup-
integration-tests/target/it-repo org.apache.maven.plugins:

maven-clean-plugin:clean

-Dsurefire.version=2.19.2-SNAPSHOT -DtestNgVersion=5.7
-DtestNgClassifier=jdk15 -DforkMode=perthread -DreuseForks=false
-DreuseForks=true -DthreadCount=1 -DtestProperty=testValue_${
surefire.threadNumber}_${surefire.forkNumber}

org.apache.maven.plugins.

surefire:maven-dump-pid-plugin:dump-pid test

specifically:

-DreuseForks=false -DreuseForks=true

Looking at SurefireLauncher.java

https://github.com/apache/maven-surefire/blob/master/
surefire-integration-tests/src/test/java/org/apache/
maven/surefire/its/fixture/SurefireLauncher.java

1. the reuseForks method adds a new system property argument each

time

it’s called: -DreuseForks=
2. the forkPerThread method calls forkMode( "perthread"

).reuseForks(

false )
3. the forkOncePerThread calls forkPerThread().reuseForks( true )

So any test using SurefireLauncher’s “forkOncePerThread” method

will

end

up with two “reuseForks” system property options on the

command-line

- and

will therefore be affected by the change in system property option
precedence.

This explains why ForkModeIT fails for me locally with master, but

passes

with 3.3.9 - with current master the -DreuseForks=false option

wins,

whereas with 3.3.9 the -DreuseForks=true options wins.

If I change SurefireLauncher.forkOncePerThread to avoid

duplicating

this

system property, ie:

return forkMode( "perthread" ).reuseForks( true );

then

Re: I think we are ready for 3.5.0-alpha-1

Who seconds MNG-6150 Javadoc improvements for 3.5.0 for FIX-3.5.0? 
Functional changes, passes all tests.


Michael

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

Re: Re: Re: I think we are ready for 3.5.0-alpha-1

Hi Tibor,

I am currently running a full test bed with various Maven versions from 
Surefire master.
I will pass you all log files along with the target directory. I'll join the 
channel
at 18:30 Europe/Berlin.

Michael

> I will be on IRC in hour.
> We can talk about the other two tests.
> Can you send me logs from yesterday for CheckTestNgReportTestIT and
> Surefire772NoSurefireReportsIT ?
> 
> On Tue, Feb 14, 2017 at 3:33 PM, Michael Osipov-3 [via Maven] <
> ml-node+s40175n5898667...@n5.nabble.com> wrote:
> 
> > This test passes flawlessly.
> >
> > > Hi Michael,
> > >
> > > If you will run the build again, this test should not fail. At least I
> > hope
> > > so, because it's ok on my side
> > > https://builds.apache.org/job/maven-surefire/org.apache.
> > maven.surefire$surefire-integration-tests/1673/
> > testReport/junit/org.apache.maven.surefire.its/ConsoleOutputIT/
> > largerSoutThanMemory/
> > > I will check Jenkins build result tomorrow morning.
> > >
> > >
> > > On Mon, Feb 13, 2017 at 10:47 PM, Michael Osipov-2 [via Maven] <
> > > [hidden email] >
> > wrote:
> > >
> > > > Am 2017-02-13 um 21:36 schrieb Tibor Digana:
> > > > > I am working with Michael on FreeBSD issues.
> > > > > I will try to fix one IT today and I will analyse the logs with next
> > two
> > > > > ITs.
> > > > > Did we change something regarding SITE in Maven 3.5.0-SNAPSHOT ?
> > > >
> > > > I was able to tackle the constant failure of
> > > > Surefire772NoSurefireReportsIT on FreeBSD. Maven from master works,
> > but
> > > > fails from MNG-6169. The root cause is the ugprade of the Clean Plugin
> > > > to 3.0.0. 2.6.1 works flawlessly, 3.0.1-SNAPSHOT fails too. I consider
> > > > the Clean Plugin broken is some way.
> > > >
> > > > @Karl Heinz, do you think yo could assist in finding the bug?
> > > >
> > > > I will continue with the other failures on FreeBSD, Maven from master
> > > > and Surefire from master.
> > > >
> > > > Michael
> > > >
> > > >
> > > > > On Mon, Feb 13, 2017 at 6:32 PM, Tibor Digana-2 [via Maven] <
> > > > > [hidden email]  > type=node=5898560=0>>
> > > > wrote:
> > > > >
> > > > >> The HEAD in Surefire has a Jira fix 1322 which is using the same IT
> > > > which
> > > > >> failed on FreeBSD. So I simply included FreeBSD fix in the test
> > > > >> Surefire141PluggableProvidersIT.
> > > > >> I hope you will be happy with that.
> > > > >> The only last IT which fails and I did not have time to investigate
> > is
> > > > >> Surefire772NoSurefireReportsIT. This is from your log you sent me:
> > > > >>
> > > > >> testOptionalSurefireReportGeneration(org.apache.maven.surefire.its.jiras.
> >
> > > >
> > > > >> Surefire772NoSurefireReportsIT)
> > > > >> Time elapsed: 0 sec  <<< FAILURE!
> > > > >> java.lang.AssertionError: Expecting failsafe report file
> > > > >> at org.junit.Assert.fail(Assert.java:88)
> > > > >> at org.junit.Assert.assertTrue(Assert.java:41)
> > > > >> at
> > > > >> org.apache.maven.surefire.its.jiras.Surefire772NoSurefireReportsIT.
> >
> > > > >> testOptionalSurefireReportGeneration(Surefire772NoSurefireReportsIT.java:75)
> >
> > > >
> > > > >>
> > > > >>
> > > > >>
> > > > >> On Mon, Feb 13, 2017 at 4:49 PM, Michael Osipov <[hidden email]
> > > > >> > wrote:
> > > > >>
> > > > >>> I am currently running a patched version of Maven with the
> > offensive
> > > > >>> commit reverted against Surefire master on FreeBSD 10.3-STABLE.
> > I'll
> > > > see
> > > > >>> wether this is the cause in an hour or so.
> > > > >>>
> > > > >>> Michael
> > > > >>>
> > > >  I’ve logged the change in precedence as
> > https://issues.apache.org/
> > > > >>> jira/browse/MNG-6172 since this has the potential to break CI
> > builds
> > > > >>> which relied on the previous last-one-wins behaviour
> > > > 
> > > >  On Monday, 13 February 2017 at 06:54, Tibor Digana wrote:
> > > > 
> > > > > Exactly this is the problem - forkMode and reuseForks in one
> > > > >> function.
> > > > > I will open Jira and push a fix.
> > > > >
> > > > > On Mon, Feb 13, 2017 at 2:44 AM, Stuart McCulloch [via Maven] <
> > > > > [hidden email]
> > > > >>  (mailto:
> > > > ml-node+
> > > > >>> [hidden email]  > type=node=5898532=2>)>
> > > >
> > > > >> wrote:
> > > > >
> > > > >> So I tweaked ForkedLauncher from maven-verifier to dump out the
> > > > >>> forked
> > > > >> command to log.txt and at least one of the failing ITs has a
> > > > >>> duplicated
> > > > >> system property on the command-line:
> > > > >>
> > > > >> mvn -e --batch-mode -Dmaven.repo.local=/tmp/maven-
> > > > >> surefire/surefire-integration-tests/../surefire-setup-
> > > > >> integration-tests/target/it-repo org.apache.maven.plugins:
> > > > >>> maven-clean-plugin:clean
> > > > >>

Re: Re: I think we are ready for 3.5.0-alpha-1

2017-02-14 Thread Tibor Digana

I will be on IRC in hour.
We can talk about the other two tests.
Can you send me logs from yesterday for CheckTestNgReportTestIT and
Surefire772NoSurefireReportsIT ?

On Tue, Feb 14, 2017 at 3:33 PM, Michael Osipov-3 [via Maven] <
ml-node+s40175n5898667...@n5.nabble.com> wrote:

> This test passes flawlessly.
>
> > Hi Michael,
> >
> > If you will run the build again, this test should not fail. At least I
> hope
> > so, because it's ok on my side
> > https://builds.apache.org/job/maven-surefire/org.apache.
> maven.surefire$surefire-integration-tests/1673/
> testReport/junit/org.apache.maven.surefire.its/ConsoleOutputIT/
> largerSoutThanMemory/
> > I will check Jenkins build result tomorrow morning.
> >
> >
> > On Mon, Feb 13, 2017 at 10:47 PM, Michael Osipov-2 [via Maven] <
> > [hidden email] >
> wrote:
> >
> > > Am 2017-02-13 um 21:36 schrieb Tibor Digana:
> > > > I am working with Michael on FreeBSD issues.
> > > > I will try to fix one IT today and I will analyse the logs with next
> two
> > > > ITs.
> > > > Did we change something regarding SITE in Maven 3.5.0-SNAPSHOT ?
> > >
> > > I was able to tackle the constant failure of
> > > Surefire772NoSurefireReportsIT on FreeBSD. Maven from master works,
> but
> > > fails from MNG-6169. The root cause is the ugprade of the Clean Plugin
> > > to 3.0.0. 2.6.1 works flawlessly, 3.0.1-SNAPSHOT fails too. I consider
> > > the Clean Plugin broken is some way.
> > >
> > > @Karl Heinz, do you think yo could assist in finding the bug?
> > >
> > > I will continue with the other failures on FreeBSD, Maven from master
> > > and Surefire from master.
> > >
> > > Michael
> > >
> > >
> > > > On Mon, Feb 13, 2017 at 6:32 PM, Tibor Digana-2 [via Maven] <
> > > > [hidden email]  type=node=5898560=0>>
> > > wrote:
> > > >
> > > >> The HEAD in Surefire has a Jira fix 1322 which is using the same IT
> > > which
> > > >> failed on FreeBSD. So I simply included FreeBSD fix in the test
> > > >> Surefire141PluggableProvidersIT.
> > > >> I hope you will be happy with that.
> > > >> The only last IT which fails and I did not have time to investigate
> is
> > > >> Surefire772NoSurefireReportsIT. This is from your log you sent me:
> > > >>
> > > >> testOptionalSurefireReportGeneration(org.apache.maven.surefire.its.jiras.
>
> > >
> > > >> Surefire772NoSurefireReportsIT)
> > > >> Time elapsed: 0 sec  <<< FAILURE!
> > > >> java.lang.AssertionError: Expecting failsafe report file
> > > >> at org.junit.Assert.fail(Assert.java:88)
> > > >> at org.junit.Assert.assertTrue(Assert.java:41)
> > > >> at
> > > >> org.apache.maven.surefire.its.jiras.Surefire772NoSurefireReportsIT.
>
> > > >> testOptionalSurefireReportGeneration(Surefire772NoSurefireReportsIT.java:75)
>
> > >
> > > >>
> > > >>
> > > >>
> > > >> On Mon, Feb 13, 2017 at 4:49 PM, Michael Osipov <[hidden email]
> > > >> > wrote:
> > > >>
> > > >>> I am currently running a patched version of Maven with the
> offensive
> > > >>> commit reverted against Surefire master on FreeBSD 10.3-STABLE.
> I'll
> > > see
> > > >>> wether this is the cause in an hour or so.
> > > >>>
> > > >>> Michael
> > > >>>
> > >  I’ve logged the change in precedence as
> https://issues.apache.org/
> > > >>> jira/browse/MNG-6172 since this has the potential to break CI
> builds
> > > >>> which relied on the previous last-one-wins behaviour
> > > 
> > >  On Monday, 13 February 2017 at 06:54, Tibor Digana wrote:
> > > 
> > > > Exactly this is the problem - forkMode and reuseForks in one
> > > >> function.
> > > > I will open Jira and push a fix.
> > > >
> > > > On Mon, Feb 13, 2017 at 2:44 AM, Stuart McCulloch [via Maven] <
> > > > [hidden email]
> > > >>  (mailto:
> > > ml-node+
> > > >>> [hidden email]  type=node=5898532=2>)>
> > >
> > > >> wrote:
> > > >
> > > >> So I tweaked ForkedLauncher from maven-verifier to dump out the
> > > >>> forked
> > > >> command to log.txt and at least one of the failing ITs has a
> > > >>> duplicated
> > > >> system property on the command-line:
> > > >>
> > > >> mvn -e --batch-mode -Dmaven.repo.local=/tmp/maven-
> > > >> surefire/surefire-integration-tests/../surefire-setup-
> > > >> integration-tests/target/it-repo org.apache.maven.plugins:
> > > >>> maven-clean-plugin:clean
> > > >> -Dsurefire.version=2.19.2-SNAPSHOT -DtestNgVersion=5.7
> > > >> -DtestNgClassifier=jdk15 -DforkMode=perthread
> -DreuseForks=false
> > > >> -DreuseForks=true -DthreadCount=1 -DtestProperty=testValue_${
> > > >> surefire.threadNumber}_${surefire.forkNumber}
> > > >>> org.apache.maven.plugins.
> > > >> surefire:maven-dump-pid-plugin:dump-pid test
> > > >>
> > > >> specifically:
> > > >>
> > > >> -DreuseForks=false -DreuseForks=true
> > >

Re: Re: I think we are ready for 3.5.0-alpha-1

This test passes flawlessly.

> Hi Michael,
> 
> If you will run the build again, this test should not fail. At least I hope
> so, because it's ok on my side
> https://builds.apache.org/job/maven-surefire/org.apache.maven.surefire$surefire-integration-tests/1673/testReport/junit/org.apache.maven.surefire.its/ConsoleOutputIT/largerSoutThanMemory/
> I will check Jenkins build result tomorrow morning.
> 
> 
> On Mon, Feb 13, 2017 at 10:47 PM, Michael Osipov-2 [via Maven] <
> ml-node+s40175n589856...@n5.nabble.com> wrote:
> 
> > Am 2017-02-13 um 21:36 schrieb Tibor Digana:
> > > I am working with Michael on FreeBSD issues.
> > > I will try to fix one IT today and I will analyse the logs with next two
> > > ITs.
> > > Did we change something regarding SITE in Maven 3.5.0-SNAPSHOT ?
> >
> > I was able to tackle the constant failure of
> > Surefire772NoSurefireReportsIT on FreeBSD. Maven from master works, but
> > fails from MNG-6169. The root cause is the ugprade of the Clean Plugin
> > to 3.0.0. 2.6.1 works flawlessly, 3.0.1-SNAPSHOT fails too. I consider
> > the Clean Plugin broken is some way.
> >
> > @Karl Heinz, do you think yo could assist in finding the bug?
> >
> > I will continue with the other failures on FreeBSD, Maven from master
> > and Surefire from master.
> >
> > Michael
> >
> >
> > > On Mon, Feb 13, 2017 at 6:32 PM, Tibor Digana-2 [via Maven] <
> > > [hidden email] >
> > wrote:
> > >
> > >> The HEAD in Surefire has a Jira fix 1322 which is using the same IT
> > which
> > >> failed on FreeBSD. So I simply included FreeBSD fix in the test
> > >> Surefire141PluggableProvidersIT.
> > >> I hope you will be happy with that.
> > >> The only last IT which fails and I did not have time to investigate is
> > >> Surefire772NoSurefireReportsIT. This is from your log you sent me:
> > >>
> > >> testOptionalSurefireReportGeneration(org.apache.maven.surefire.its.jiras.
> >
> > >> Surefire772NoSurefireReportsIT)
> > >> Time elapsed: 0 sec  <<< FAILURE!
> > >> java.lang.AssertionError: Expecting failsafe report file
> > >> at org.junit.Assert.fail(Assert.java:88)
> > >> at org.junit.Assert.assertTrue(Assert.java:41)
> > >> at
> > >> org.apache.maven.surefire.its.jiras.Surefire772NoSurefireReportsIT.
> > >> testOptionalSurefireReportGeneration(Surefire772NoSurefireReportsIT.java:75)
> >
> > >>
> > >>
> > >>
> > >> On Mon, Feb 13, 2017 at 4:49 PM, Michael Osipov <[hidden email]
> > >> > wrote:
> > >>
> > >>> I am currently running a patched version of Maven with the offensive
> > >>> commit reverted against Surefire master on FreeBSD 10.3-STABLE. I'll
> > see
> > >>> wether this is the cause in an hour or so.
> > >>>
> > >>> Michael
> > >>>
> >  I’ve logged the change in precedence as https://issues.apache.org/
> > >>> jira/browse/MNG-6172 since this has the potential to break CI builds
> > >>> which relied on the previous last-one-wins behaviour
> > 
> >  On Monday, 13 February 2017 at 06:54, Tibor Digana wrote:
> > 
> > > Exactly this is the problem - forkMode and reuseForks in one
> > >> function.
> > > I will open Jira and push a fix.
> > >
> > > On Mon, Feb 13, 2017 at 2:44 AM, Stuart McCulloch [via Maven] <
> > > [hidden email]
> > >>  (mailto:
> > ml-node+
> > >>> [hidden email] )>
> >
> > >> wrote:
> > >
> > >> So I tweaked ForkedLauncher from maven-verifier to dump out the
> > >>> forked
> > >> command to log.txt and at least one of the failing ITs has a
> > >>> duplicated
> > >> system property on the command-line:
> > >>
> > >> mvn -e --batch-mode -Dmaven.repo.local=/tmp/maven-
> > >> surefire/surefire-integration-tests/../surefire-setup-
> > >> integration-tests/target/it-repo org.apache.maven.plugins:
> > >>> maven-clean-plugin:clean
> > >> -Dsurefire.version=2.19.2-SNAPSHOT -DtestNgVersion=5.7
> > >> -DtestNgClassifier=jdk15 -DforkMode=perthread -DreuseForks=false
> > >> -DreuseForks=true -DthreadCount=1 -DtestProperty=testValue_${
> > >> surefire.threadNumber}_${surefire.forkNumber}
> > >>> org.apache.maven.plugins.
> > >> surefire:maven-dump-pid-plugin:dump-pid test
> > >>
> > >> specifically:
> > >>
> > >> -DreuseForks=false -DreuseForks=true
> > >>
> > >> Looking at SurefireLauncher.java
> > >>
> > >> https://github.com/apache/maven-surefire/blob/master/
> > >> surefire-integration-tests/src/test/java/org/apache/
> > >> maven/surefire/its/fixture/SurefireLauncher.java
> > >>
> > >> 1. the reuseForks method adds a new system property argument each
> > >>> time
> > >> it’s called: -DreuseForks=
> > >> 2. the forkPerThread method calls forkMode( "perthread"
> > >> ).reuseForks(
> > >> false )
> > >> 3. the forkOncePerThread calls

Re: I think we are ready for 3.5.0-alpha-1

Hi Michael,

If you will run the build again, this test should not fail. At least I hope
so, because it's ok on my side
https://builds.apache.org/job/maven-surefire/org.apache.maven.surefire$surefire-integration-tests/1673/testReport/junit/org.apache.maven.surefire.its/ConsoleOutputIT/largerSoutThanMemory/
I will check Jenkins build result tomorrow morning.


On Mon, Feb 13, 2017 at 10:47 PM, Michael Osipov-2 [via Maven] <
ml-node+s40175n589856...@n5.nabble.com> wrote:

> Am 2017-02-13 um 21:36 schrieb Tibor Digana:
> > I am working with Michael on FreeBSD issues.
> > I will try to fix one IT today and I will analyse the logs with next two
> > ITs.
> > Did we change something regarding SITE in Maven 3.5.0-SNAPSHOT ?
>
> I was able to tackle the constant failure of
> Surefire772NoSurefireReportsIT on FreeBSD. Maven from master works, but
> fails from MNG-6169. The root cause is the ugprade of the Clean Plugin
> to 3.0.0. 2.6.1 works flawlessly, 3.0.1-SNAPSHOT fails too. I consider
> the Clean Plugin broken is some way.
>
> @Karl Heinz, do you think yo could assist in finding the bug?
>
> I will continue with the other failures on FreeBSD, Maven from master
> and Surefire from master.
>
> Michael
>
>
> > On Mon, Feb 13, 2017 at 6:32 PM, Tibor Digana-2 [via Maven] <
> > [hidden email] >
> wrote:
> >
> >> The HEAD in Surefire has a Jira fix 1322 which is using the same IT
> which
> >> failed on FreeBSD. So I simply included FreeBSD fix in the test
> >> Surefire141PluggableProvidersIT.
> >> I hope you will be happy with that.
> >> The only last IT which fails and I did not have time to investigate is
> >> Surefire772NoSurefireReportsIT. This is from your log you sent me:
> >>
> >> testOptionalSurefireReportGeneration(org.apache.maven.surefire.its.jiras.
>
> >> Surefire772NoSurefireReportsIT)
> >> Time elapsed: 0 sec  <<< FAILURE!
> >> java.lang.AssertionError: Expecting failsafe report file
> >> at org.junit.Assert.fail(Assert.java:88)
> >> at org.junit.Assert.assertTrue(Assert.java:41)
> >> at
> >> org.apache.maven.surefire.its.jiras.Surefire772NoSurefireReportsIT.
> >> testOptionalSurefireReportGeneration(Surefire772NoSurefireReportsIT.java:75)
>
> >>
> >>
> >>
> >> On Mon, Feb 13, 2017 at 4:49 PM, Michael Osipov <[hidden email]
> >> > wrote:
> >>
> >>> I am currently running a patched version of Maven with the offensive
> >>> commit reverted against Surefire master on FreeBSD 10.3-STABLE. I'll
> see
> >>> wether this is the cause in an hour or so.
> >>>
> >>> Michael
> >>>
>  I’ve logged the change in precedence as https://issues.apache.org/
> >>> jira/browse/MNG-6172 since this has the potential to break CI builds
> >>> which relied on the previous last-one-wins behaviour
> 
>  On Monday, 13 February 2017 at 06:54, Tibor Digana wrote:
> 
> > Exactly this is the problem - forkMode and reuseForks in one
> >> function.
> > I will open Jira and push a fix.
> >
> > On Mon, Feb 13, 2017 at 2:44 AM, Stuart McCulloch [via Maven] <
> > [hidden email]
> >>  (mailto:
> ml-node+
> >>> [hidden email] )>
>
> >> wrote:
> >
> >> So I tweaked ForkedLauncher from maven-verifier to dump out the
> >>> forked
> >> command to log.txt and at least one of the failing ITs has a
> >>> duplicated
> >> system property on the command-line:
> >>
> >> mvn -e --batch-mode -Dmaven.repo.local=/tmp/maven-
> >> surefire/surefire-integration-tests/../surefire-setup-
> >> integration-tests/target/it-repo org.apache.maven.plugins:
> >>> maven-clean-plugin:clean
> >> -Dsurefire.version=2.19.2-SNAPSHOT -DtestNgVersion=5.7
> >> -DtestNgClassifier=jdk15 -DforkMode=perthread -DreuseForks=false
> >> -DreuseForks=true -DthreadCount=1 -DtestProperty=testValue_${
> >> surefire.threadNumber}_${surefire.forkNumber}
> >>> org.apache.maven.plugins.
> >> surefire:maven-dump-pid-plugin:dump-pid test
> >>
> >> specifically:
> >>
> >> -DreuseForks=false -DreuseForks=true
> >>
> >> Looking at SurefireLauncher.java
> >>
> >> https://github.com/apache/maven-surefire/blob/master/
> >> surefire-integration-tests/src/test/java/org/apache/
> >> maven/surefire/its/fixture/SurefireLauncher.java
> >>
> >> 1. the reuseForks method adds a new system property argument each
> >>> time
> >> it’s called: -DreuseForks=
> >> 2. the forkPerThread method calls forkMode( "perthread"
> >> ).reuseForks(
> >> false )
> >> 3. the forkOncePerThread calls forkPerThread().reuseForks( true )
> >>
> >> So any test using SurefireLauncher’s “forkOncePerThread” method
> >> will
> >>> end
> >> up with two “reuseForks” system property options on the
> >> command-line
> >>> - and
> >> will therefore be affected by the change in

Re: I think we are ready for 3.5.0-alpha-1

2017-02-13 Thread Michael Osipov


Am 2017-02-13 um 21:36 schrieb Tibor Digana:

I am working with Michael on FreeBSD issues.
I will try to fix one IT today and I will analyse the logs with next two
ITs.
Did we change something regarding SITE in Maven 3.5.0-SNAPSHOT ?


I was able to tackle the constant failure of 
Surefire772NoSurefireReportsIT on FreeBSD. Maven from master works, but 
fails from MNG-6169. The root cause is the ugprade of the Clean Plugin 
to 3.0.0. 2.6.1 works flawlessly, 3.0.1-SNAPSHOT fails too. I consider 
the Clean Plugin broken is some way.


@Karl Heinz, do you think yo could assist in finding the bug?

I will continue with the other failures on FreeBSD, Maven from master 
and Surefire from master.


Michael



On Mon, Feb 13, 2017 at 6:32 PM, Tibor Digana-2 [via Maven] <
ml-node+s40175n5898532...@n5.nabble.com> wrote:


The HEAD in Surefire has a Jira fix 1322 which is using the same IT which
failed on FreeBSD. So I simply included FreeBSD fix in the test
Surefire141PluggableProvidersIT.
I hope you will be happy with that.
The only last IT which fails and I did not have time to investigate is
Surefire772NoSurefireReportsIT. This is from your log you sent me:

testOptionalSurefireReportGeneration(org.apache.maven.surefire.its.jiras.
Surefire772NoSurefireReportsIT)
Time elapsed: 0 sec  <<< FAILURE!
java.lang.AssertionError: Expecting failsafe report file
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at
org.apache.maven.surefire.its.jiras.Surefire772NoSurefireReportsIT.
testOptionalSurefireReportGeneration(Surefire772NoSurefireReportsIT.java:75)



On Mon, Feb 13, 2017 at 4:49 PM, Michael Osipov <[hidden email]
> wrote:


I am currently running a patched version of Maven with the offensive
commit reverted against Surefire master on FreeBSD 10.3-STABLE. I'll see
wether this is the cause in an hour or so.

Michael


I’ve logged the change in precedence as https://issues.apache.org/

jira/browse/MNG-6172 since this has the potential to break CI builds
which relied on the previous last-one-wins behaviour


On Monday, 13 February 2017 at 06:54, Tibor Digana wrote:


Exactly this is the problem - forkMode and reuseForks in one

function.

I will open Jira and push a fix.

On Mon, Feb 13, 2017 at 2:44 AM, Stuart McCulloch [via Maven] <
[hidden email]

 (mailto:ml-node+

[hidden email] )>

wrote:



So I tweaked ForkedLauncher from maven-verifier to dump out the

forked

command to log.txt and at least one of the failing ITs has a

duplicated

system property on the command-line:

mvn -e --batch-mode -Dmaven.repo.local=/tmp/maven-
surefire/surefire-integration-tests/../surefire-setup-
integration-tests/target/it-repo org.apache.maven.plugins:

maven-clean-plugin:clean

-Dsurefire.version=2.19.2-SNAPSHOT -DtestNgVersion=5.7
-DtestNgClassifier=jdk15 -DforkMode=perthread -DreuseForks=false
-DreuseForks=true -DthreadCount=1 -DtestProperty=testValue_${
surefire.threadNumber}_${surefire.forkNumber}

org.apache.maven.plugins.

surefire:maven-dump-pid-plugin:dump-pid test

specifically:

-DreuseForks=false -DreuseForks=true

Looking at SurefireLauncher.java

https://github.com/apache/maven-surefire/blob/master/
surefire-integration-tests/src/test/java/org/apache/
maven/surefire/its/fixture/SurefireLauncher.java

1. the reuseForks method adds a new system property argument each

time

it’s called: -DreuseForks=
2. the forkPerThread method calls forkMode( "perthread"

).reuseForks(

false )
3. the forkOncePerThread calls forkPerThread().reuseForks( true )

So any test using SurefireLauncher’s “forkOncePerThread” method

will

end

up with two “reuseForks” system property options on the

command-line

- and

will therefore be affected by the change in system property option
precedence.

This explains why ForkModeIT fails for me locally with master, but

passes

with 3.3.9 - with current master the -DreuseForks=false option

wins,

whereas with 3.3.9 the -DreuseForks=true options wins.

If I change SurefireLauncher.forkOncePerThread to avoid

duplicating

this

system property, ie:

return forkMode( "perthread" ).reuseForks( true );

then ForkModeIT passes with both current master and previous Maven
releases.

Hope that helps...

--
Cheers, Stuart


On Monday, 13 February 2017 at 01:32, Stuart McCulloch wrote:


Ironically I got those results the wrong way round when

cutting+pasting

:)


To clarify, when testing

mvn -Dmaven.repo.local=/tmp/aaa -Dmaven.repo.local=/tmp/zzz

validate


with previous Maven releases the last option wins:

-Dmaven.repo.local=/tmp/zzz

whereas with current master the first option wins:

-Dmaven.repo.local=/tmp/aaa

On Monday, 13 February 2017 at 00:19, Stuart McCulloch wrote:


Using the following command on a small test project:

mvn -Dmaven.repo.local=/tmp/aaa -Dmaven.repo.local=/tmp/zzz

validate


and

Re: Re: I think we are ready for 3.5.0-alpha-1

I am working with Michael on FreeBSD issues.
I will try to fix one IT today and I will analyse the logs with next two
ITs.
Did we change something regarding SITE in Maven 3.5.0-SNAPSHOT ?

On Mon, Feb 13, 2017 at 6:32 PM, Tibor Digana-2 [via Maven] <
ml-node+s40175n5898532...@n5.nabble.com> wrote:

> The HEAD in Surefire has a Jira fix 1322 which is using the same IT which
> failed on FreeBSD. So I simply included FreeBSD fix in the test
> Surefire141PluggableProvidersIT.
> I hope you will be happy with that.
> The only last IT which fails and I did not have time to investigate is
> Surefire772NoSurefireReportsIT. This is from your log you sent me:
>
> testOptionalSurefireReportGeneration(org.apache.maven.surefire.its.jiras.
> Surefire772NoSurefireReportsIT)
> Time elapsed: 0 sec  <<< FAILURE!
> java.lang.AssertionError: Expecting failsafe report file
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at
> org.apache.maven.surefire.its.jiras.Surefire772NoSurefireReportsIT.
> testOptionalSurefireReportGeneration(Surefire772NoSurefireReportsIT.java:75)
>
>
>
> On Mon, Feb 13, 2017 at 4:49 PM, Michael Osipov <[hidden email]
> > wrote:
>
> > I am currently running a patched version of Maven with the offensive
> > commit reverted against Surefire master on FreeBSD 10.3-STABLE. I'll see
> > wether this is the cause in an hour or so.
> >
> > Michael
> >
> > > I’ve logged the change in precedence as https://issues.apache.org/
> > jira/browse/MNG-6172 since this has the potential to break CI builds
> > which relied on the previous last-one-wins behaviour
> > >
> > > On Monday, 13 February 2017 at 06:54, Tibor Digana wrote:
> > >
> > > > Exactly this is the problem - forkMode and reuseForks in one
> function.
> > > > I will open Jira and push a fix.
> > > >
> > > > On Mon, Feb 13, 2017 at 2:44 AM, Stuart McCulloch [via Maven] <
> > > > [hidden email]
>  (mailto:ml-node+
> > [hidden email] )>
> wrote:
> > > >
> > > > > So I tweaked ForkedLauncher from maven-verifier to dump out the
> > forked
> > > > > command to log.txt and at least one of the failing ITs has a
> > duplicated
> > > > > system property on the command-line:
> > > > >
> > > > > mvn -e --batch-mode -Dmaven.repo.local=/tmp/maven-
> > > > > surefire/surefire-integration-tests/../surefire-setup-
> > > > > integration-tests/target/it-repo org.apache.maven.plugins:
> > maven-clean-plugin:clean
> > > > > -Dsurefire.version=2.19.2-SNAPSHOT -DtestNgVersion=5.7
> > > > > -DtestNgClassifier=jdk15 -DforkMode=perthread -DreuseForks=false
> > > > > -DreuseForks=true -DthreadCount=1 -DtestProperty=testValue_${
> > > > > surefire.threadNumber}_${surefire.forkNumber}
> > org.apache.maven.plugins.
> > > > > surefire:maven-dump-pid-plugin:dump-pid test
> > > > >
> > > > > specifically:
> > > > >
> > > > > -DreuseForks=false -DreuseForks=true
> > > > >
> > > > > Looking at SurefireLauncher.java
> > > > >
> > > > > https://github.com/apache/maven-surefire/blob/master/
> > > > > surefire-integration-tests/src/test/java/org/apache/
> > > > > maven/surefire/its/fixture/SurefireLauncher.java
> > > > >
> > > > > 1. the reuseForks method adds a new system property argument each
> > time
> > > > > it’s called: -DreuseForks=
> > > > > 2. the forkPerThread method calls forkMode( "perthread"
> ).reuseForks(
> > > > > false )
> > > > > 3. the forkOncePerThread calls forkPerThread().reuseForks( true )
> > > > >
> > > > > So any test using SurefireLauncher’s “forkOncePerThread” method
> will
> > end
> > > > > up with two “reuseForks” system property options on the
> command-line
> > - and
> > > > > will therefore be affected by the change in system property option
> > > > > precedence.
> > > > >
> > > > > This explains why ForkModeIT fails for me locally with master, but
> > passes
> > > > > with 3.3.9 - with current master the -DreuseForks=false option
> wins,
> > > > > whereas with 3.3.9 the -DreuseForks=true options wins.
> > > > >
> > > > > If I change SurefireLauncher.forkOncePerThread to avoid
> duplicating
> > this
> > > > > system property, ie:
> > > > >
> > > > > return forkMode( "perthread" ).reuseForks( true );
> > > > >
> > > > > then ForkModeIT passes with both current master and previous Maven
> > > > > releases.
> > > > >
> > > > > Hope that helps...
> > > > >
> > > > > --
> > > > > Cheers, Stuart
> > > > >
> > > > >
> > > > > On Monday, 13 February 2017 at 01:32, Stuart McCulloch wrote:
> > > > >
> > > > > > Ironically I got those results the wrong way round when
> > cutting+pasting
> > > > > :)
> > > > > >
> > > > > > To clarify, when testing
> > > > > >
> > > > > > mvn -Dmaven.repo.local=/tmp/aaa -Dmaven.repo.local=/tmp/zzz
> > validate
> > > > > >
> > > > > > with previous Maven releases the last option wins:
> > > > > >
> > > > > > -Dmaven.repo.local=/tmp/zzz
> > > > >

Re: Re: I think we are ready for 3.5.0-alpha-1

The HEAD in Surefire has a Jira fix 1322 which is using the same IT which
failed on FreeBSD. So I simply included FreeBSD fix in the test
Surefire141PluggableProvidersIT.
I hope you will be happy with that.
The only last IT which fails and I did not have time to investigate is
Surefire772NoSurefireReportsIT. This is from your log you sent me:

testOptionalSurefireReportGeneration(org.apache.maven.surefire.its.jiras.Surefire772NoSurefireReportsIT)
Time elapsed: 0 sec  <<< FAILURE!
java.lang.AssertionError: Expecting failsafe report file
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at
org.apache.maven.surefire.its.jiras.Surefire772NoSurefireReportsIT.testOptionalSurefireReportGeneration(Surefire772NoSurefireReportsIT.java:75)


On Mon, Feb 13, 2017 at 4:49 PM, Michael Osipov <1983-01...@gmx.net> wrote:

> I am currently running a patched version of Maven with the offensive
> commit reverted against Surefire master on FreeBSD 10.3-STABLE. I'll see
> wether this is the cause in an hour or so.
>
> Michael
>
> > I’ve logged the change in precedence as https://issues.apache.org/
> jira/browse/MNG-6172 since this has the potential to break CI builds
> which relied on the previous last-one-wins behaviour
> >
> > On Monday, 13 February 2017 at 06:54, Tibor Digana wrote:
> >
> > > Exactly this is the problem - forkMode and reuseForks in one function.
> > > I will open Jira and push a fix.
> > >
> > > On Mon, Feb 13, 2017 at 2:44 AM, Stuart McCulloch [via Maven] <
> > > ml-node+s40175n5898461...@n5.nabble.com (mailto:ml-node+
> s40175n5898461...@n5.nabble.com)> wrote:
> > >
> > > > So I tweaked ForkedLauncher from maven-verifier to dump out the
> forked
> > > > command to log.txt and at least one of the failing ITs has a
> duplicated
> > > > system property on the command-line:
> > > >
> > > > mvn -e --batch-mode -Dmaven.repo.local=/tmp/maven-
> > > > surefire/surefire-integration-tests/../surefire-setup-
> > > > integration-tests/target/it-repo org.apache.maven.plugins:
> maven-clean-plugin:clean
> > > > -Dsurefire.version=2.19.2-SNAPSHOT -DtestNgVersion=5.7
> > > > -DtestNgClassifier=jdk15 -DforkMode=perthread -DreuseForks=false
> > > > -DreuseForks=true -DthreadCount=1 -DtestProperty=testValue_${
> > > > surefire.threadNumber}_${surefire.forkNumber}
> org.apache.maven.plugins.
> > > > surefire:maven-dump-pid-plugin:dump-pid test
> > > >
> > > > specifically:
> > > >
> > > > -DreuseForks=false -DreuseForks=true
> > > >
> > > > Looking at SurefireLauncher.java
> > > >
> > > > https://github.com/apache/maven-surefire/blob/master/
> > > > surefire-integration-tests/src/test/java/org/apache/
> > > > maven/surefire/its/fixture/SurefireLauncher.java
> > > >
> > > > 1. the reuseForks method adds a new system property argument each
> time
> > > > it’s called: -DreuseForks=
> > > > 2. the forkPerThread method calls forkMode( "perthread" ).reuseForks(
> > > > false )
> > > > 3. the forkOncePerThread calls forkPerThread().reuseForks( true )
> > > >
> > > > So any test using SurefireLauncher’s “forkOncePerThread” method will
> end
> > > > up with two “reuseForks” system property options on the command-line
> - and
> > > > will therefore be affected by the change in system property option
> > > > precedence.
> > > >
> > > > This explains why ForkModeIT fails for me locally with master, but
> passes
> > > > with 3.3.9 - with current master the -DreuseForks=false option wins,
> > > > whereas with 3.3.9 the -DreuseForks=true options wins.
> > > >
> > > > If I change SurefireLauncher.forkOncePerThread to avoid duplicating
> this
> > > > system property, ie:
> > > >
> > > > return forkMode( "perthread" ).reuseForks( true );
> > > >
> > > > then ForkModeIT passes with both current master and previous Maven
> > > > releases.
> > > >
> > > > Hope that helps...
> > > >
> > > > --
> > > > Cheers, Stuart
> > > >
> > > >
> > > > On Monday, 13 February 2017 at 01:32, Stuart McCulloch wrote:
> > > >
> > > > > Ironically I got those results the wrong way round when
> cutting+pasting
> > > > :)
> > > > >
> > > > > To clarify, when testing
> > > > >
> > > > > mvn -Dmaven.repo.local=/tmp/aaa -Dmaven.repo.local=/tmp/zzz
> validate
> > > > >
> > > > > with previous Maven releases the last option wins:
> > > > >
> > > > > -Dmaven.repo.local=/tmp/zzz
> > > > >
> > > > > whereas with current master the first option wins:
> > > > >
> > > > > -Dmaven.repo.local=/tmp/aaa
> > > > >
> > > > > On Monday, 13 February 2017 at 00:19, Stuart McCulloch wrote:
> > > > >
> > > > > > Using the following command on a small test project:
> > > > > >
> > > > > > mvn -Dmaven.repo.local=/tmp/aaa -Dmaven.repo.local=/tmp/zzz
> validate
> > > > > >
> > > > > > and checking whether the “aaa” or “zzz” directory is created
> gives
> > > > these results for previous Maven releases:
> > > > > >
> > > > > > 2.0.11 aaa
> > > > > > 2.2.1 aaa
> > > > > > 3.0.5 aaa
> > > > > > 3.1.1 aaa
> > > > > > 3.2.5 aaa
> > > > > > 3.3.9

Re: Re: I think we are ready for 3.5.0-alpha-1

Michael, can you please connect to IRC mvn dev?
I would like to discuss regarding FreeBSD.
Thx

On Mon, Feb 13, 2017 at 4:49 PM, Michael Osipov <1983-01...@gmx.net> wrote:

> I am currently running a patched version of Maven with the offensive
> commit reverted against Surefire master on FreeBSD 10.3-STABLE. I'll see
> wether this is the cause in an hour or so.
>
> Michael
>
> > I’ve logged the change in precedence as https://issues.apache.org/
> jira/browse/MNG-6172 since this has the potential to break CI builds
> which relied on the previous last-one-wins behaviour
> >
> > On Monday, 13 February 2017 at 06:54, Tibor Digana wrote:
> >
> > > Exactly this is the problem - forkMode and reuseForks in one function.
> > > I will open Jira and push a fix.
> > >
> > > On Mon, Feb 13, 2017 at 2:44 AM, Stuart McCulloch [via Maven] <
> > > ml-node+s40175n5898461...@n5.nabble.com (mailto:ml-node+
> s40175n5898461...@n5.nabble.com)> wrote:
> > >
> > > > So I tweaked ForkedLauncher from maven-verifier to dump out the
> forked
> > > > command to log.txt and at least one of the failing ITs has a
> duplicated
> > > > system property on the command-line:
> > > >
> > > > mvn -e --batch-mode -Dmaven.repo.local=/tmp/maven-
> > > > surefire/surefire-integration-tests/../surefire-setup-
> > > > integration-tests/target/it-repo org.apache.maven.plugins:
> maven-clean-plugin:clean
> > > > -Dsurefire.version=2.19.2-SNAPSHOT -DtestNgVersion=5.7
> > > > -DtestNgClassifier=jdk15 -DforkMode=perthread -DreuseForks=false
> > > > -DreuseForks=true -DthreadCount=1 -DtestProperty=testValue_${
> > > > surefire.threadNumber}_${surefire.forkNumber}
> org.apache.maven.plugins.
> > > > surefire:maven-dump-pid-plugin:dump-pid test
> > > >
> > > > specifically:
> > > >
> > > > -DreuseForks=false -DreuseForks=true
> > > >
> > > > Looking at SurefireLauncher.java
> > > >
> > > > https://github.com/apache/maven-surefire/blob/master/
> > > > surefire-integration-tests/src/test/java/org/apache/
> > > > maven/surefire/its/fixture/SurefireLauncher.java
> > > >
> > > > 1. the reuseForks method adds a new system property argument each
> time
> > > > it’s called: -DreuseForks=
> > > > 2. the forkPerThread method calls forkMode( "perthread" ).reuseForks(
> > > > false )
> > > > 3. the forkOncePerThread calls forkPerThread().reuseForks( true )
> > > >
> > > > So any test using SurefireLauncher’s “forkOncePerThread” method will
> end
> > > > up with two “reuseForks” system property options on the command-line
> - and
> > > > will therefore be affected by the change in system property option
> > > > precedence.
> > > >
> > > > This explains why ForkModeIT fails for me locally with master, but
> passes
> > > > with 3.3.9 - with current master the -DreuseForks=false option wins,
> > > > whereas with 3.3.9 the -DreuseForks=true options wins.
> > > >
> > > > If I change SurefireLauncher.forkOncePerThread to avoid duplicating
> this
> > > > system property, ie:
> > > >
> > > > return forkMode( "perthread" ).reuseForks( true );
> > > >
> > > > then ForkModeIT passes with both current master and previous Maven
> > > > releases.
> > > >
> > > > Hope that helps...
> > > >
> > > > --
> > > > Cheers, Stuart
> > > >
> > > >
> > > > On Monday, 13 February 2017 at 01:32, Stuart McCulloch wrote:
> > > >
> > > > > Ironically I got those results the wrong way round when
> cutting+pasting
> > > > :)
> > > > >
> > > > > To clarify, when testing
> > > > >
> > > > > mvn -Dmaven.repo.local=/tmp/aaa -Dmaven.repo.local=/tmp/zzz
> validate
> > > > >
> > > > > with previous Maven releases the last option wins:
> > > > >
> > > > > -Dmaven.repo.local=/tmp/zzz
> > > > >
> > > > > whereas with current master the first option wins:
> > > > >
> > > > > -Dmaven.repo.local=/tmp/aaa
> > > > >
> > > > > On Monday, 13 February 2017 at 00:19, Stuart McCulloch wrote:
> > > > >
> > > > > > Using the following command on a small test project:
> > > > > >
> > > > > > mvn -Dmaven.repo.local=/tmp/aaa -Dmaven.repo.local=/tmp/zzz
> validate
> > > > > >
> > > > > > and checking whether the “aaa” or “zzz” directory is created
> gives
> > > > these results for previous Maven releases:
> > > > > >
> > > > > > 2.0.11 aaa
> > > > > > 2.2.1 aaa
> > > > > > 3.0.5 aaa
> > > > > > 3.1.1 aaa
> > > > > > 3.2.5 aaa
> > > > > > 3.3.9 aaa
> > > > > >
> > > > > > whereas current master gives a different result:
> > > > > >
> > > > > > master zzz
> > > > > >
> > > > > > which confirms the precedence of CLI arguments is currently
> reversed
> > > > on master compared to previous releases
> > > > > >
> > > > > > --
> > > > > > Cheers, Stuart
> > > > > >
> > > > > >
> > > > > > On Sunday, 12 February 2017 at 23:53, Stuart McCulloch wrote:
> > > > > >
> > > > > > > git bisect is pointing to the following commit:
> > > > > > >
> > > > > > > https://github.com/apache/maven/commit/
> > > > ca4303031357a7decaee8de770b71fb2c2fedd28
> > > > > > >
> > > > > > > if I revert this change then the wrong PID issue disappears and
> > >

Re: Re: I think we are ready for 3.5.0-alpha-1

I will push branch SUREFIRE-1322 which has a fix for freebsd.

On Mon, Feb 13, 2017 at 4:49 PM, Michael Osipov <1983-01...@gmx.net> wrote:

> I am currently running a patched version of Maven with the offensive
> commit reverted against Surefire master on FreeBSD 10.3-STABLE. I'll see
> wether this is the cause in an hour or so.
>
> Michael
>
> > I’ve logged the change in precedence as https://issues.apache.org/
> jira/browse/MNG-6172 since this has the potential to break CI builds
> which relied on the previous last-one-wins behaviour
> >
> > On Monday, 13 February 2017 at 06:54, Tibor Digana wrote:
> >
> > > Exactly this is the problem - forkMode and reuseForks in one function.
> > > I will open Jira and push a fix.
> > >
> > > On Mon, Feb 13, 2017 at 2:44 AM, Stuart McCulloch [via Maven] <
> > > ml-node+s40175n5898461...@n5.nabble.com (mailto:ml-node+
> s40175n5898461...@n5.nabble.com)> wrote:
> > >
> > > > So I tweaked ForkedLauncher from maven-verifier to dump out the
> forked
> > > > command to log.txt and at least one of the failing ITs has a
> duplicated
> > > > system property on the command-line:
> > > >
> > > > mvn -e --batch-mode -Dmaven.repo.local=/tmp/maven-
> > > > surefire/surefire-integration-tests/../surefire-setup-
> > > > integration-tests/target/it-repo org.apache.maven.plugins:
> maven-clean-plugin:clean
> > > > -Dsurefire.version=2.19.2-SNAPSHOT -DtestNgVersion=5.7
> > > > -DtestNgClassifier=jdk15 -DforkMode=perthread -DreuseForks=false
> > > > -DreuseForks=true -DthreadCount=1 -DtestProperty=testValue_${
> > > > surefire.threadNumber}_${surefire.forkNumber}
> org.apache.maven.plugins.
> > > > surefire:maven-dump-pid-plugin:dump-pid test
> > > >
> > > > specifically:
> > > >
> > > > -DreuseForks=false -DreuseForks=true
> > > >
> > > > Looking at SurefireLauncher.java
> > > >
> > > > https://github.com/apache/maven-surefire/blob/master/
> > > > surefire-integration-tests/src/test/java/org/apache/
> > > > maven/surefire/its/fixture/SurefireLauncher.java
> > > >
> > > > 1. the reuseForks method adds a new system property argument each
> time
> > > > it’s called: -DreuseForks=
> > > > 2. the forkPerThread method calls forkMode( "perthread" ).reuseForks(
> > > > false )
> > > > 3. the forkOncePerThread calls forkPerThread().reuseForks( true )
> > > >
> > > > So any test using SurefireLauncher’s “forkOncePerThread” method will
> end
> > > > up with two “reuseForks” system property options on the command-line
> - and
> > > > will therefore be affected by the change in system property option
> > > > precedence.
> > > >
> > > > This explains why ForkModeIT fails for me locally with master, but
> passes
> > > > with 3.3.9 - with current master the -DreuseForks=false option wins,
> > > > whereas with 3.3.9 the -DreuseForks=true options wins.
> > > >
> > > > If I change SurefireLauncher.forkOncePerThread to avoid duplicating
> this
> > > > system property, ie:
> > > >
> > > > return forkMode( "perthread" ).reuseForks( true );
> > > >
> > > > then ForkModeIT passes with both current master and previous Maven
> > > > releases.
> > > >
> > > > Hope that helps...
> > > >
> > > > --
> > > > Cheers, Stuart
> > > >
> > > >
> > > > On Monday, 13 February 2017 at 01:32, Stuart McCulloch wrote:
> > > >
> > > > > Ironically I got those results the wrong way round when
> cutting+pasting
> > > > :)
> > > > >
> > > > > To clarify, when testing
> > > > >
> > > > > mvn -Dmaven.repo.local=/tmp/aaa -Dmaven.repo.local=/tmp/zzz
> validate
> > > > >
> > > > > with previous Maven releases the last option wins:
> > > > >
> > > > > -Dmaven.repo.local=/tmp/zzz
> > > > >
> > > > > whereas with current master the first option wins:
> > > > >
> > > > > -Dmaven.repo.local=/tmp/aaa
> > > > >
> > > > > On Monday, 13 February 2017 at 00:19, Stuart McCulloch wrote:
> > > > >
> > > > > > Using the following command on a small test project:
> > > > > >
> > > > > > mvn -Dmaven.repo.local=/tmp/aaa -Dmaven.repo.local=/tmp/zzz
> validate
> > > > > >
> > > > > > and checking whether the “aaa” or “zzz” directory is created
> gives
> > > > these results for previous Maven releases:
> > > > > >
> > > > > > 2.0.11 aaa
> > > > > > 2.2.1 aaa
> > > > > > 3.0.5 aaa
> > > > > > 3.1.1 aaa
> > > > > > 3.2.5 aaa
> > > > > > 3.3.9 aaa
> > > > > >
> > > > > > whereas current master gives a different result:
> > > > > >
> > > > > > master zzz
> > > > > >
> > > > > > which confirms the precedence of CLI arguments is currently
> reversed
> > > > on master compared to previous releases
> > > > > >
> > > > > > --
> > > > > > Cheers, Stuart
> > > > > >
> > > > > >
> > > > > > On Sunday, 12 February 2017 at 23:53, Stuart McCulloch wrote:
> > > > > >
> > > > > > > git bisect is pointing to the following commit:
> > > > > > >
> > > > > > > https://github.com/apache/maven/commit/
> > > > ca4303031357a7decaee8de770b71fb2c2fedd28
> > > > > > >
> > > > > > > if I revert this change then the wrong PID issue disappears and
> > > > ForkModeIT passes again
> > > >

Re: Re: I think we are ready for 3.5.0-alpha-1

2017-02-13 Thread Michael Osipov

I am currently running a patched version of Maven with the offensive commit 
reverted against Surefire master on FreeBSD 10.3-STABLE. I'll see wether this 
is the cause in an hour or so.

Michael

> I’ve logged the change in precedence as 
> https://issues.apache.org/jira/browse/MNG-6172 since this has the potential 
> to break CI builds which relied on the previous last-one-wins behaviour
> 
> On Monday, 13 February 2017 at 06:54, Tibor Digana wrote:
> 
> > Exactly this is the problem - forkMode and reuseForks in one function.
> > I will open Jira and push a fix.
> >  
> > On Mon, Feb 13, 2017 at 2:44 AM, Stuart McCulloch [via Maven] <
> > ml-node+s40175n5898461...@n5.nabble.com 
> > (mailto:ml-node+s40175n5898461...@n5.nabble.com)> wrote:
> >  
> > > So I tweaked ForkedLauncher from maven-verifier to dump out the forked
> > > command to log.txt and at least one of the failing ITs has a duplicated
> > > system property on the command-line:
> > >  
> > > mvn -e --batch-mode -Dmaven.repo.local=/tmp/maven-
> > > surefire/surefire-integration-tests/../surefire-setup-
> > > integration-tests/target/it-repo 
> > > org.apache.maven.plugins:maven-clean-plugin:clean
> > > -Dsurefire.version=2.19.2-SNAPSHOT -DtestNgVersion=5.7
> > > -DtestNgClassifier=jdk15 -DforkMode=perthread -DreuseForks=false
> > > -DreuseForks=true -DthreadCount=1 -DtestProperty=testValue_${
> > > surefire.threadNumber}_${surefire.forkNumber} org.apache.maven.plugins.
> > > surefire:maven-dump-pid-plugin:dump-pid test
> > >  
> > > specifically:
> > >  
> > > -DreuseForks=false -DreuseForks=true
> > >  
> > > Looking at SurefireLauncher.java
> > >  
> > > https://github.com/apache/maven-surefire/blob/master/
> > > surefire-integration-tests/src/test/java/org/apache/
> > > maven/surefire/its/fixture/SurefireLauncher.java
> > >  
> > > 1. the reuseForks method adds a new system property argument each time
> > > it’s called: -DreuseForks=
> > > 2. the forkPerThread method calls forkMode( "perthread" ).reuseForks(
> > > false )
> > > 3. the forkOncePerThread calls forkPerThread().reuseForks( true )
> > >  
> > > So any test using SurefireLauncher’s “forkOncePerThread” method will end
> > > up with two “reuseForks” system property options on the command-line - and
> > > will therefore be affected by the change in system property option
> > > precedence.
> > >  
> > > This explains why ForkModeIT fails for me locally with master, but passes
> > > with 3.3.9 - with current master the -DreuseForks=false option wins,
> > > whereas with 3.3.9 the -DreuseForks=true options wins.
> > >  
> > > If I change SurefireLauncher.forkOncePerThread to avoid duplicating this
> > > system property, ie:
> > >  
> > > return forkMode( "perthread" ).reuseForks( true );
> > >  
> > > then ForkModeIT passes with both current master and previous Maven
> > > releases.
> > >  
> > > Hope that helps...
> > >  
> > > --
> > > Cheers, Stuart
> > >  
> > >  
> > > On Monday, 13 February 2017 at 01:32, Stuart McCulloch wrote:
> > >  
> > > > Ironically I got those results the wrong way round when cutting+pasting
> > > :)
> > > >  
> > > > To clarify, when testing
> > > >  
> > > > mvn -Dmaven.repo.local=/tmp/aaa -Dmaven.repo.local=/tmp/zzz validate
> > > >  
> > > > with previous Maven releases the last option wins:
> > > >  
> > > > -Dmaven.repo.local=/tmp/zzz
> > > >  
> > > > whereas with current master the first option wins:
> > > >  
> > > > -Dmaven.repo.local=/tmp/aaa
> > > >  
> > > > On Monday, 13 February 2017 at 00:19, Stuart McCulloch wrote:
> > > >  
> > > > > Using the following command on a small test project:
> > > > >  
> > > > > mvn -Dmaven.repo.local=/tmp/aaa -Dmaven.repo.local=/tmp/zzz validate
> > > > >  
> > > > > and checking whether the “aaa” or “zzz” directory is created gives
> > > these results for previous Maven releases:
> > > > >  
> > > > > 2.0.11 aaa
> > > > > 2.2.1 aaa
> > > > > 3.0.5 aaa
> > > > > 3.1.1 aaa
> > > > > 3.2.5 aaa
> > > > > 3.3.9 aaa
> > > > >  
> > > > > whereas current master gives a different result:
> > > > >  
> > > > > master zzz
> > > > >  
> > > > > which confirms the precedence of CLI arguments is currently reversed
> > > on master compared to previous releases
> > > > >  
> > > > > --
> > > > > Cheers, Stuart
> > > > >  
> > > > >  
> > > > > On Sunday, 12 February 2017 at 23:53, Stuart McCulloch wrote:
> > > > >  
> > > > > > git bisect is pointing to the following commit:
> > > > > >  
> > > > > > https://github.com/apache/maven/commit/
> > > ca4303031357a7decaee8de770b71fb2c2fedd28
> > > > > >  
> > > > > > if I revert this change then the wrong PID issue disappears and
> > > ForkModeIT passes again
> > > > > >  
> > > > > > I suspect that reversing the whole array of system property
> > > definitions, while solving MNG-6078, is breaking precedence of arguments 
> > > on
> > > the CLI (which then affects these tests)
> > > > > >  
> > > > > > On Sunday, 12 February 2017 at 20:26, Tibor Digana wrote:
> > > > > >  
> > >

Re: I think we are ready for 3.5.0-alpha-1

2017-02-13 Thread Stephen Connolly

I view this as a must fix

On 13 February 2017 at 10:34, Stuart McCulloch  wrote:

> I’ve logged the change in precedence as https://issues.apache.org/
> jira/browse/MNG-6172 since this has the potential to break CI builds
> which relied on the previous last-one-wins behaviour
>
> On Monday, 13 February 2017 at 06:54, Tibor Digana wrote:
>
> > Exactly this is the problem - forkMode and reuseForks in one function.
> > I will open Jira and push a fix.
> >
> > On Mon, Feb 13, 2017 at 2:44 AM, Stuart McCulloch [via Maven] <
> > ml-node+s40175n5898461...@n5.nabble.com (mailto:ml-node+
> s40175n5898461...@n5.nabble.com)> wrote:
> >
> > > So I tweaked ForkedLauncher from maven-verifier to dump out the forked
> > > command to log.txt and at least one of the failing ITs has a duplicated
> > > system property on the command-line:
> > >
> > > mvn -e --batch-mode -Dmaven.repo.local=/tmp/maven-
> > > surefire/surefire-integration-tests/../surefire-setup-
> > > integration-tests/target/it-repo org.apache.maven.plugins:
> maven-clean-plugin:clean
> > > -Dsurefire.version=2.19.2-SNAPSHOT -DtestNgVersion=5.7
> > > -DtestNgClassifier=jdk15 -DforkMode=perthread -DreuseForks=false
> > > -DreuseForks=true -DthreadCount=1 -DtestProperty=testValue_${
> > > surefire.threadNumber}_${surefire.forkNumber}
> org.apache.maven.plugins.
> > > surefire:maven-dump-pid-plugin:dump-pid test
> > >
> > > specifically:
> > >
> > > -DreuseForks=false -DreuseForks=true
> > >
> > > Looking at SurefireLauncher.java
> > >
> > > https://github.com/apache/maven-surefire/blob/master/
> > > surefire-integration-tests/src/test/java/org/apache/
> > > maven/surefire/its/fixture/SurefireLauncher.java
> > >
> > > 1. the reuseForks method adds a new system property argument each time
> > > it’s called: -DreuseForks=
> > > 2. the forkPerThread method calls forkMode( "perthread" ).reuseForks(
> > > false )
> > > 3. the forkOncePerThread calls forkPerThread().reuseForks( true )
> > >
> > > So any test using SurefireLauncher’s “forkOncePerThread” method will
> end
> > > up with two “reuseForks” system property options on the command-line -
> and
> > > will therefore be affected by the change in system property option
> > > precedence.
> > >
> > > This explains why ForkModeIT fails for me locally with master, but
> passes
> > > with 3.3.9 - with current master the -DreuseForks=false option wins,
> > > whereas with 3.3.9 the -DreuseForks=true options wins.
> > >
> > > If I change SurefireLauncher.forkOncePerThread to avoid duplicating
> this
> > > system property, ie:
> > >
> > > return forkMode( "perthread" ).reuseForks( true );
> > >
> > > then ForkModeIT passes with both current master and previous Maven
> > > releases.
> > >
> > > Hope that helps...
> > >
> > > --
> > > Cheers, Stuart
> > >
> > >
> > > On Monday, 13 February 2017 at 01:32, Stuart McCulloch wrote:
> > >
> > > > Ironically I got those results the wrong way round when
> cutting+pasting
> > > :)
> > > >
> > > > To clarify, when testing
> > > >
> > > > mvn -Dmaven.repo.local=/tmp/aaa -Dmaven.repo.local=/tmp/zzz validate
> > > >
> > > > with previous Maven releases the last option wins:
> > > >
> > > > -Dmaven.repo.local=/tmp/zzz
> > > >
> > > > whereas with current master the first option wins:
> > > >
> > > > -Dmaven.repo.local=/tmp/aaa
> > > >
> > > > On Monday, 13 February 2017 at 00:19, Stuart McCulloch wrote:
> > > >
> > > > > Using the following command on a small test project:
> > > > >
> > > > > mvn -Dmaven.repo.local=/tmp/aaa -Dmaven.repo.local=/tmp/zzz
> validate
> > > > >
> > > > > and checking whether the “aaa” or “zzz” directory is created gives
> > > these results for previous Maven releases:
> > > > >
> > > > > 2.0.11 aaa
> > > > > 2.2.1 aaa
> > > > > 3.0.5 aaa
> > > > > 3.1.1 aaa
> > > > > 3.2.5 aaa
> > > > > 3.3.9 aaa
> > > > >
> > > > > whereas current master gives a different result:
> > > > >
> > > > > master zzz
> > > > >
> > > > > which confirms the precedence of CLI arguments is currently
> reversed
> > > on master compared to previous releases
> > > > >
> > > > > --
> > > > > Cheers, Stuart
> > > > >
> > > > >
> > > > > On Sunday, 12 February 2017 at 23:53, Stuart McCulloch wrote:
> > > > >
> > > > > > git bisect is pointing to the following commit:
> > > > > >
> > > > > > https://github.com/apache/maven/commit/
> > > ca4303031357a7decaee8de770b71fb2c2fedd28
> > > > > >
> > > > > > if I revert this change then the wrong PID issue disappears and
> > > ForkModeIT passes again
> > > > > >
> > > > > > I suspect that reversing the whole array of system property
> > > definitions, while solving MNG-6078, is breaking precedence of
> arguments on
> > > the CLI (which then affects these tests)
> > > > > >
> > > > > > On Sunday, 12 February 2017 at 20:26, Tibor Digana wrote:
> > > > > >
> > > > > > > So this is a local build status of surefire running on the top
> of
> > > certain
> > > > > > > Maven Version.
> > > > > > > Maven 3.3.9 OK on my side
> > > > > > >

Re: I think we are ready for 3.5.0-alpha-1

2017-02-13 Thread Stuart McCulloch

I’ve logged the change in precedence as 
https://issues.apache.org/jira/browse/MNG-6172 since this has the potential to 
break CI builds which relied on the previous last-one-wins behaviour

On Monday, 13 February 2017 at 06:54, Tibor Digana wrote:

> Exactly this is the problem - forkMode and reuseForks in one function.
> I will open Jira and push a fix.
>  
> On Mon, Feb 13, 2017 at 2:44 AM, Stuart McCulloch [via Maven] <
> ml-node+s40175n5898461...@n5.nabble.com 
> (mailto:ml-node+s40175n5898461...@n5.nabble.com)> wrote:
>  
> > So I tweaked ForkedLauncher from maven-verifier to dump out the forked
> > command to log.txt and at least one of the failing ITs has a duplicated
> > system property on the command-line:
> >  
> > mvn -e --batch-mode -Dmaven.repo.local=/tmp/maven-
> > surefire/surefire-integration-tests/../surefire-setup-
> > integration-tests/target/it-repo 
> > org.apache.maven.plugins:maven-clean-plugin:clean
> > -Dsurefire.version=2.19.2-SNAPSHOT -DtestNgVersion=5.7
> > -DtestNgClassifier=jdk15 -DforkMode=perthread -DreuseForks=false
> > -DreuseForks=true -DthreadCount=1 -DtestProperty=testValue_${
> > surefire.threadNumber}_${surefire.forkNumber} org.apache.maven.plugins.
> > surefire:maven-dump-pid-plugin:dump-pid test
> >  
> > specifically:
> >  
> > -DreuseForks=false -DreuseForks=true
> >  
> > Looking at SurefireLauncher.java
> >  
> > https://github.com/apache/maven-surefire/blob/master/
> > surefire-integration-tests/src/test/java/org/apache/
> > maven/surefire/its/fixture/SurefireLauncher.java
> >  
> > 1. the reuseForks method adds a new system property argument each time
> > it’s called: -DreuseForks=
> > 2. the forkPerThread method calls forkMode( "perthread" ).reuseForks(
> > false )
> > 3. the forkOncePerThread calls forkPerThread().reuseForks( true )
> >  
> > So any test using SurefireLauncher’s “forkOncePerThread” method will end
> > up with two “reuseForks” system property options on the command-line - and
> > will therefore be affected by the change in system property option
> > precedence.
> >  
> > This explains why ForkModeIT fails for me locally with master, but passes
> > with 3.3.9 - with current master the -DreuseForks=false option wins,
> > whereas with 3.3.9 the -DreuseForks=true options wins.
> >  
> > If I change SurefireLauncher.forkOncePerThread to avoid duplicating this
> > system property, ie:
> >  
> > return forkMode( "perthread" ).reuseForks( true );
> >  
> > then ForkModeIT passes with both current master and previous Maven
> > releases.
> >  
> > Hope that helps...
> >  
> > --
> > Cheers, Stuart
> >  
> >  
> > On Monday, 13 February 2017 at 01:32, Stuart McCulloch wrote:
> >  
> > > Ironically I got those results the wrong way round when cutting+pasting
> > :)
> > >  
> > > To clarify, when testing
> > >  
> > > mvn -Dmaven.repo.local=/tmp/aaa -Dmaven.repo.local=/tmp/zzz validate
> > >  
> > > with previous Maven releases the last option wins:
> > >  
> > > -Dmaven.repo.local=/tmp/zzz
> > >  
> > > whereas with current master the first option wins:
> > >  
> > > -Dmaven.repo.local=/tmp/aaa
> > >  
> > > On Monday, 13 February 2017 at 00:19, Stuart McCulloch wrote:
> > >  
> > > > Using the following command on a small test project:
> > > >  
> > > > mvn -Dmaven.repo.local=/tmp/aaa -Dmaven.repo.local=/tmp/zzz validate
> > > >  
> > > > and checking whether the “aaa” or “zzz” directory is created gives
> > these results for previous Maven releases:
> > > >  
> > > > 2.0.11 aaa
> > > > 2.2.1 aaa
> > > > 3.0.5 aaa
> > > > 3.1.1 aaa
> > > > 3.2.5 aaa
> > > > 3.3.9 aaa
> > > >  
> > > > whereas current master gives a different result:
> > > >  
> > > > master zzz
> > > >  
> > > > which confirms the precedence of CLI arguments is currently reversed
> > on master compared to previous releases
> > > >  
> > > > --
> > > > Cheers, Stuart
> > > >  
> > > >  
> > > > On Sunday, 12 February 2017 at 23:53, Stuart McCulloch wrote:
> > > >  
> > > > > git bisect is pointing to the following commit:
> > > > >  
> > > > > https://github.com/apache/maven/commit/
> > ca4303031357a7decaee8de770b71fb2c2fedd28
> > > > >  
> > > > > if I revert this change then the wrong PID issue disappears and
> > ForkModeIT passes again
> > > > >  
> > > > > I suspect that reversing the whole array of system property
> > definitions, while solving MNG-6078, is breaking precedence of arguments on
> > the CLI (which then affects these tests)
> > > > >  
> > > > > On Sunday, 12 February 2017 at 20:26, Tibor Digana wrote:
> > > > >  
> > > > > > So this is a local build status of surefire running on the top of
> > certain
> > > > > > Maven Version.
> > > > > > Maven 3.3.9 OK on my side
> > > > > > Maven 3.5.0-SNAPSHOT failed. Wrong PIDs, other tests failed on
> > > > > >  
> > > > >  
> > > >  
> > >  
> >  
> > freebsd and
> > > > > > not on Win7, so I asked Michael for logs which I do not have.
> > > > > > So I am going to investigate.
> > > > > >  
> > > > > > On Sun, Feb 12, 2017 at

Re: I think we are ready for 3.5.0-alpha-1

Exactly this is the problem - forkMode and reuseForks in one function.
I will open Jira and push a fix.

On Mon, Feb 13, 2017 at 2:44 AM, Stuart McCulloch [via Maven] <
ml-node+s40175n5898461...@n5.nabble.com> wrote:

> So I tweaked ForkedLauncher from maven-verifier to dump out the forked
> command to log.txt and at least one of the failing ITs has a duplicated
> system property on the command-line:
>
> mvn -e --batch-mode -Dmaven.repo.local=/tmp/maven-
> surefire/surefire-integration-tests/../surefire-setup-
> integration-tests/target/it-repo 
> org.apache.maven.plugins:maven-clean-plugin:clean
> -Dsurefire.version=2.19.2-SNAPSHOT -DtestNgVersion=5.7
> -DtestNgClassifier=jdk15 -DforkMode=perthread -DreuseForks=false
> -DreuseForks=true -DthreadCount=1 -DtestProperty=testValue_${
> surefire.threadNumber}_${surefire.forkNumber} org.apache.maven.plugins.
> surefire:maven-dump-pid-plugin:dump-pid test
>
> specifically:
>
> -DreuseForks=false -DreuseForks=true
>
> Looking at SurefireLauncher.java
>
> https://github.com/apache/maven-surefire/blob/master/
> surefire-integration-tests/src/test/java/org/apache/
> maven/surefire/its/fixture/SurefireLauncher.java
>
> 1.  the reuseForks method adds a new system property argument each time
> it’s called:  -DreuseForks=
> 2.  the forkPerThread method calls forkMode( "perthread" ).reuseForks(
> false )
> 3.  the forkOncePerThread calls forkPerThread().reuseForks( true )
>
> So any test using SurefireLauncher’s “forkOncePerThread” method will end
> up with two “reuseForks” system property options on the command-line - and
> will therefore be affected by the change in system property option
> precedence.
>
> This explains why ForkModeIT fails for me locally with master, but passes
> with 3.3.9 - with current master the -DreuseForks=false option wins,
> whereas with 3.3.9 the -DreuseForks=true options wins.
>
> If I change SurefireLauncher.forkOncePerThread to avoid duplicating this
> system property, ie:
>
> return forkMode( "perthread" ).reuseForks( true );
>
> then ForkModeIT passes with both current master and previous Maven
> releases.
>
> Hope that helps...
>
> --
> Cheers, Stuart
>
>
> On Monday, 13 February 2017 at 01:32, Stuart McCulloch wrote:
>
> > Ironically I got those results the wrong way round when cutting+pasting
> :)
> >
> > To clarify, when testing
> >
> > mvn -Dmaven.repo.local=/tmp/aaa -Dmaven.repo.local=/tmp/zzz validate
> >
> > with previous Maven releases the last option wins:
> >
> > -Dmaven.repo.local=/tmp/zzz
> >
> > whereas with current master the first option wins:
> >
> > -Dmaven.repo.local=/tmp/aaa
> >
> > On Monday, 13 February 2017 at 00:19, Stuart McCulloch wrote:
> >
> > > Using the following command on a small test project:
> > >
> > > mvn -Dmaven.repo.local=/tmp/aaa -Dmaven.repo.local=/tmp/zzz validate
> > >
> > > and checking whether the “aaa” or “zzz” directory is created gives
> these results for previous Maven releases:
> > >
> > > 2.0.11 aaa
> > > 2.2.1 aaa
> > > 3.0.5 aaa
> > > 3.1.1 aaa
> > > 3.2.5 aaa
> > > 3.3.9 aaa
> > >
> > > whereas current master gives a different result:
> > >
> > > master zzz
> > >
> > > which confirms the precedence of CLI arguments is currently reversed
> on master compared to previous releases
> > >
> > > --
> > > Cheers, Stuart
> > >
> > >
> > > On Sunday, 12 February 2017 at 23:53, Stuart McCulloch wrote:
> > >
> > > > git bisect is pointing to the following commit:
> > > >
> > > > https://github.com/apache/maven/commit/
> ca4303031357a7decaee8de770b71fb2c2fedd28
> > > >
> > > > if I revert this change then the wrong PID issue disappears and
> ForkModeIT passes again
> > > >
> > > > I suspect that reversing the whole array of system property
> definitions, while solving MNG-6078, is breaking precedence of arguments on
> the CLI (which then affects these tests)
> > > >
> > > > On Sunday, 12 February 2017 at 20:26, Tibor Digana wrote:
> > > >
> > > > > So this is a local build status of surefire running on the top of
> certain
> > > > > Maven Version.
> > > > > Maven 3.3.9 OK on my side
> > > > > Maven 3.5.0-SNAPSHOT failed. Wrong PIDs, other tests failed on
> freebsd and
> > > > > not on Win7, so I asked Michael for logs which I do not have.
> > > > > So I am going to investigate.
> > > > >
> > > > > On Sun, Feb 12, 2017 at 9:05 PM, stephenconnolly [via Maven] <
> > > > > [hidden email]
>  (mailto:[hidden
> email] )> wrote:
> > > > >
> > > > > > Can you pop on HipChat with infra?
> > > > > >
> > > > > > You may need them to grab the files from the agent for you (or
> modify the
> > > > > > Jenkinsfile temporarily to archive the bits you need)
> > > > > >
> > > > > > On Sun 12 Feb 2017 at 19:55, Tibor Digana <[hidden email]
> > > > > > > wrote:
> > > > > >
> > > > > > > There is build process for surefire
> > > > > > >
> > > > > > >

Re: I think we are ready for 3.5.0-alpha-1

So I tweaked ForkedLauncher from maven-verifier to dump out the forked command 
to log.txt and at least one of the failing ITs has a duplicated system property 
on the command-line:

mvn -e --batch-mode 
-Dmaven.repo.local=/tmp/maven-surefire/surefire-integration-tests/../surefire-setup-integration-tests/target/it-repo
 org.apache.maven.plugins:maven-clean-plugin:clean 
-Dsurefire.version=2.19.2-SNAPSHOT -DtestNgVersion=5.7 -DtestNgClassifier=jdk15 
-DforkMode=perthread -DreuseForks=false -DreuseForks=true -DthreadCount=1 
-DtestProperty=testValue_${surefire.threadNumber}_${surefire.forkNumber} 
org.apache.maven.plugins.surefire:maven-dump-pid-plugin:dump-pid test

specifically:

-DreuseForks=false -DreuseForks=true

Looking at SurefireLauncher.java

https://github.com/apache/maven-surefire/blob/master/surefire-integration-tests/src/test/java/org/apache/maven/surefire/its/fixture/SurefireLauncher.java

1.  the reuseForks method adds a new system property argument each time it’s 
called:  -DreuseForks=
2.  the forkPerThread method calls forkMode( "perthread" ).reuseForks( false )
3.  the forkOncePerThread calls forkPerThread().reuseForks( true )

So any test using SurefireLauncher’s “forkOncePerThread” method will end up 
with two “reuseForks” system property options on the command-line - and will 
therefore be affected by the change in system property option precedence.

This explains why ForkModeIT fails for me locally with master, but passes with 
3.3.9 - with current master the -DreuseForks=false option wins, whereas with 
3.3.9 the -DreuseForks=true options wins.

If I change SurefireLauncher.forkOncePerThread to avoid duplicating this system 
property, ie:

return forkMode( "perthread" ).reuseForks( true );

then ForkModeIT passes with both current master and previous Maven releases.

Hope that helps...

--  
Cheers, Stuart


On Monday, 13 February 2017 at 01:32, Stuart McCulloch wrote:

> Ironically I got those results the wrong way round when cutting+pasting :)
>  
> To clarify, when testing
>  
> mvn -Dmaven.repo.local=/tmp/aaa -Dmaven.repo.local=/tmp/zzz validate
>  
> with previous Maven releases the last option wins:
>  
> -Dmaven.repo.local=/tmp/zzz
>  
> whereas with current master the first option wins:
>  
> -Dmaven.repo.local=/tmp/aaa  
>  
> On Monday, 13 February 2017 at 00:19, Stuart McCulloch wrote:
>  
> > Using the following command on a small test project:
> >  
> > mvn -Dmaven.repo.local=/tmp/aaa -Dmaven.repo.local=/tmp/zzz validate
> >  
> > and checking whether the “aaa” or “zzz” directory is created gives these 
> > results for previous Maven releases:
> >  
> > 2.0.11 aaa
> > 2.2.1 aaa
> > 3.0.5 aaa
> > 3.1.1 aaa
> > 3.2.5 aaa
> > 3.3.9 aaa
> >  
> > whereas current master gives a different result:
> >  
> > master zzz  
> >  
> > which confirms the precedence of CLI arguments is currently reversed on 
> > master compared to previous releases
> >  
> > --  
> > Cheers, Stuart
> >  
> >  
> > On Sunday, 12 February 2017 at 23:53, Stuart McCulloch wrote:
> >  
> > > git bisect is pointing to the following commit:
> > >  
> > > https://github.com/apache/maven/commit/ca4303031357a7decaee8de770b71fb2c2fedd28
> > >  
> > > if I revert this change then the wrong PID issue disappears and 
> > > ForkModeIT passes again
> > >  
> > > I suspect that reversing the whole array of system property definitions, 
> > > while solving MNG-6078, is breaking precedence of arguments on the CLI 
> > > (which then affects these tests)  
> > >  
> > > On Sunday, 12 February 2017 at 20:26, Tibor Digana wrote:
> > >  
> > > > So this is a local build status of surefire running on the top of 
> > > > certain
> > > > Maven Version.
> > > > Maven 3.3.9 OK on my side
> > > > Maven 3.5.0-SNAPSHOT failed. Wrong PIDs, other tests failed on freebsd 
> > > > and
> > > > not on Win7, so I asked Michael for logs which I do not have.
> > > > So I am going to investigate.
> > > >  
> > > > On Sun, Feb 12, 2017 at 9:05 PM, stephenconnolly [via Maven] <
> > > > ml-node+s40175n5898384...@n5.nabble.com 
> > > > (mailto:ml-node+s40175n5898384...@n5.nabble.com)> wrote:
> > > >  
> > > > > Can you pop on HipChat with infra?
> > > > >  
> > > > > You may need them to grab the files from the agent for you (or modify 
> > > > > the
> > > > > Jenkinsfile temporarily to archive the bits you need)
> > > > >  
> > > > > On Sun 12 Feb 2017 at 19:55, Tibor Digana <[hidden email]
> > > > > > wrote:
> > > > >  
> > > > > > There is build process for surefire
> > > > > >  
> > > > > > https://builds.apache.org/view/Maven/job/maven-master-
> > > > > release-status-test-surefire-linux
> > > > > > with Jenkins file.
> > > > > > This particular build fails with test
> > > > > >  
> > > > > > Surefire141PluggableProvidersIT
> > > > > >  
> > > > > > It is only one and different from your local build result.
> > > > > >  
> > > > > > I asked Stephen to enable Workspace, because I need to have

Re: I think we are ready for 3.5.0-alpha-1

Ironically I got those results the wrong way round when cutting+pasting :)

To clarify, when testing

mvn -Dmaven.repo.local=/tmp/aaa -Dmaven.repo.local=/tmp/zzz validate

with previous Maven releases the last option wins:

-Dmaven.repo.local=/tmp/zzz

whereas with current master the first option wins:

-Dmaven.repo.local=/tmp/aaa  

On Monday, 13 February 2017 at 00:19, Stuart McCulloch wrote:

> Using the following command on a small test project:
>  
> mvn -Dmaven.repo.local=/tmp/aaa -Dmaven.repo.local=/tmp/zzz validate
>  
> and checking whether the “aaa” or “zzz” directory is created gives these 
> results for previous Maven releases:
>  
> 2.0.11 aaa
> 2.2.1 aaa
> 3.0.5 aaa
> 3.1.1 aaa
> 3.2.5 aaa
> 3.3.9 aaa
>  
> whereas current master gives a different result:
>  
> master zzz  
>  
> which confirms the precedence of CLI arguments is currently reversed on 
> master compared to previous releases
>  
> --  
> Cheers, Stuart
>  
>  
> On Sunday, 12 February 2017 at 23:53, Stuart McCulloch wrote:
>  
> > git bisect is pointing to the following commit:
> >  
> > https://github.com/apache/maven/commit/ca4303031357a7decaee8de770b71fb2c2fedd28
> >  
> > if I revert this change then the wrong PID issue disappears and ForkModeIT 
> > passes again
> >  
> > I suspect that reversing the whole array of system property definitions, 
> > while solving MNG-6078, is breaking precedence of arguments on the CLI 
> > (which then affects these tests)  
> >  
> > On Sunday, 12 February 2017 at 20:26, Tibor Digana wrote:
> >  
> > > So this is a local build status of surefire running on the top of certain
> > > Maven Version.
> > > Maven 3.3.9 OK on my side
> > > Maven 3.5.0-SNAPSHOT failed. Wrong PIDs, other tests failed on freebsd and
> > > not on Win7, so I asked Michael for logs which I do not have.
> > > So I am going to investigate.
> > >  
> > > On Sun, Feb 12, 2017 at 9:05 PM, stephenconnolly [via Maven] <
> > > ml-node+s40175n5898384...@n5.nabble.com 
> > > (mailto:ml-node+s40175n5898384...@n5.nabble.com)> wrote:
> > >  
> > > > Can you pop on HipChat with infra?
> > > >  
> > > > You may need them to grab the files from the agent for you (or modify 
> > > > the
> > > > Jenkinsfile temporarily to archive the bits you need)
> > > >  
> > > > On Sun 12 Feb 2017 at 19:55, Tibor Digana <[hidden email]
> > > > > wrote:
> > > >  
> > > > > There is build process for surefire
> > > > >  
> > > > > https://builds.apache.org/view/Maven/job/maven-master-
> > > > release-status-test-surefire-linux
> > > > > with Jenkins file.
> > > > > This particular build fails with test
> > > > >  
> > > > > Surefire141PluggableProvidersIT
> > > > >  
> > > > > It is only one and different from your local build result.
> > > > >  
> > > > > I asked Stephen to enable Workspace, because I need to have files from
> > > > > target folders for analysis to understand what is going on the 
> > > > > machine.
> > > > > Stephen told me that I should trigger rebuild. So I did and launched
> > > > >  
> > > >  
> > > > "Build
> > > > > with Parameters" but the build failed not running Maven build, however
> > > > > Workspace appears now.
> > > > >  
> > > > > How can I force trigger the build?
> > > > >  
> > > > >  
> > > > > https://builds.apache.org/view/Maven/job/maven-master-
> > > > release-status-test-surefire-linux/11/console
> > > > >  
> > > > > There is another build process, old one actually, and it is 
> > > > > successful.
> > > > > The difference is because I think race condition when JVM error once
> > > > >  
> > > >  
> > > > goes
> > > > > to std/err and other log in the first build with Jenkins file.
> > > > > This can, I think, be only one more assertion statement in IT but I 
> > > > > need
> > > > >  
> > > >  
> > > > to
> > > > > see Workspace.
> > > > >  
> > > > >  
> > > > >  
> > > > >  
> > > > >  
> > > > > On Sun, Feb 12, 2017 at 5:04 PM, Christian Schulte [via Maven] <
> > > > > [hidden email] 
> > > > > >
> > > > >  
> > > >  
> > > > wrote:
> > > > >  
> > > > > > @Stephen: Are there any Jenkins jobs left running the plugin ITs 
> > > > > > with
> > > > > > current Maven master? Surefire has it's own git repository. Do we 
> > > > > > have
> > > > > > some Jenkins job for this as well? It's important to run all those 
> > > > > > ITs
> > > > > > (plugins from subversion and the ones with theire own repository) 
> > > > > > with
> > > > > > what we are going to release as 3.5.0 before releasing it.
> > > > > >  
> > > > > > Regards,
> > > > > > --
> > > > > > Christian
> > > > > >  
> > > > > >  
> > > > > > -
> > > > > > To unsubscribe, e-mail: [hidden email]
> > > > > > 
> > > > > > For additional commands, e-mail: [hidden email]
> > > > > > 
> > > > > >

Re: I think we are ready for 3.5.0-alpha-1

Good catch, Stuart, but this would be only valid if we duplicated some
system property in two different POMs.
This is what I wrote in our private emails:

If I use Maven 3.5.0-SNAPSHOT and if I run this command then everything is
ok, means one PID:
surefire-integration-tests\target\ForkModeTestNGIT_
testForkModeOncePerThreadSingleThread>mvn -o -Dsurefire.version=2.19.2-SNAPSHOT
-DforkMode=perthread -DreuseForks=true -DthreadCount=1 test

If I run it in build process, then it is 3 PIDs. It looks like these system
properties are different or something else.
I will debug the build process tomorrow.

On Mon, Feb 13, 2017 at 1:20 AM, Stuart McCulloch [via Maven] <
ml-node+s40175n5898443...@n5.nabble.com> wrote:

> Using the following command on a small test project:
>
> mvn -Dmaven.repo.local=/tmp/aaa -Dmaven.repo.local=/tmp/zzz validate
>
> and checking whether the “aaa” or “zzz” directory is created gives these
> results for previous Maven releases:
>
> 2.0.11 aaa
> 2.2.1 aaa
> 3.0.5 aaa
> 3.1.1 aaa
> 3.2.5 aaa
> 3.3.9 aaa
>
> whereas current master gives a different result:
>
> master zzz
>
> which confirms the precedence of CLI arguments is currently reversed on
> master compared to previous releases
>
> --
> Cheers, Stuart
>
>
> On Sunday, 12 February 2017 at 23:53, Stuart McCulloch wrote:
>
> > git bisect is pointing to the following commit:
> >
> > https://github.com/apache/maven/commit/ca4303031357a7decaee8de770b71f
> b2c2fedd28
> >
> > if I revert this change then the wrong PID issue disappears and
> ForkModeIT passes again
> >
> > I suspect that reversing the whole array of system property definitions,
> while solving MNG-6078, is breaking precedence of arguments on the CLI
> (which then affects these tests)
> >
> > On Sunday, 12 February 2017 at 20:26, Tibor Digana wrote:
> >
> > > So this is a local build status of surefire running on the top of
> certain
> > > Maven Version.
> > > Maven 3.3.9 OK on my side
> > > Maven 3.5.0-SNAPSHOT failed. Wrong PIDs, other tests failed on freebsd
> and
> > > not on Win7, so I asked Michael for logs which I do not have.
> > > So I am going to investigate.
> > >
> > > On Sun, Feb 12, 2017 at 9:05 PM, stephenconnolly [via Maven] <
> > > [hidden email] 
> (mailto:[hidden email]
> )> wrote:
> > >
> > > > Can you pop on HipChat with infra?
> > > >
> > > > You may need them to grab the files from the agent for you (or
> modify the
> > > > Jenkinsfile temporarily to archive the bits you need)
> > > >
> > > > On Sun 12 Feb 2017 at 19:55, Tibor Digana <[hidden email]
> > > > > wrote:
> > > >
> > > > > There is build process for surefire
> > > > >
> > > > > https://builds.apache.org/view/Maven/job/maven-master-
> > > > release-status-test-surefire-linux
> > > > > with Jenkins file.
> > > > > This particular build fails with test
> > > > >
> > > > > Surefire141PluggableProvidersIT
> > > > >
> > > > > It is only one and different from your local build result.
> > > > >
> > > > > I asked Stephen to enable Workspace, because I need to have files
> from
> > > > > target folders for analysis to understand what is going on the
> machine.
> > > > > Stephen told me that I should trigger rebuild. So I did and
> launched
> > > > >
> > > >
> > > > "Build
> > > > > with Parameters" but the build failed not running Maven build,
> however
> > > > > Workspace appears now.
> > > > >
> > > > > How can I force trigger the build?
> > > > >
> > > > >
> > > > > https://builds.apache.org/view/Maven/job/maven-master-
> > > > release-status-test-surefire-linux/11/console
> > > > >
> > > > > There is another build process, old one actually, and it is
> successful.
> > > > > The difference is because I think race condition when JVM error
> once
> > > > >
> > > >
> > > > goes
> > > > > to std/err and other log in the first build with Jenkins file.
> > > > > This can, I think, be only one more assertion statement in IT but
> I need
> > > > >
> > > >
> > > > to
> > > > > see Workspace.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Sun, Feb 12, 2017 at 5:04 PM, Christian Schulte [via Maven] <
> > > > > [hidden email]  type=node=5898384=1>>
> > > > >
> > > >
> > > > wrote:
> > > > >
> > > > > > @Stephen: Are there any Jenkins jobs left running the plugin ITs
> with
> > > > > > current Maven master? Surefire has it's own git repository. Do
> we have
> > > > > > some Jenkins job for this as well? It's important to run all
> those ITs
> > > > > > (plugins from subversion and the ones with theire own
> repository) with
> > > > > > what we are going to release as 3.5.0 before releasing it.
> > > > > >
> > > > > > Regards,
> > > > > > --
> > > > > > Christian
> > > > > >
> > > > > >
> > > > > > -
>
> > > > > > To unsubscribe, e-mail: [hidden email]
> > > >

Re: I think we are ready for 3.5.0-alpha-1

Using the following command on a small test project:

mvn -Dmaven.repo.local=/tmp/aaa -Dmaven.repo.local=/tmp/zzz validate

and checking whether the “aaa” or “zzz” directory is created gives these 
results for previous Maven releases:

2.0.11 aaa
2.2.1 aaa
3.0.5 aaa
3.1.1 aaa
3.2.5 aaa
3.3.9 aaa

whereas current master gives a different result:

master zzz  

which confirms the precedence of CLI arguments is currently reversed on master 
compared to previous releases

--  
Cheers, Stuart


On Sunday, 12 February 2017 at 23:53, Stuart McCulloch wrote:

> git bisect is pointing to the following commit:
>  
> https://github.com/apache/maven/commit/ca4303031357a7decaee8de770b71fb2c2fedd28
>  
> if I revert this change then the wrong PID issue disappears and ForkModeIT 
> passes again
>  
> I suspect that reversing the whole array of system property definitions, 
> while solving MNG-6078, is breaking precedence of arguments on the CLI (which 
> then affects these tests)  
>  
> On Sunday, 12 February 2017 at 20:26, Tibor Digana wrote:
>  
> > So this is a local build status of surefire running on the top of certain
> > Maven Version.
> > Maven 3.3.9 OK on my side
> > Maven 3.5.0-SNAPSHOT failed. Wrong PIDs, other tests failed on freebsd and
> > not on Win7, so I asked Michael for logs which I do not have.
> > So I am going to investigate.
> >  
> > On Sun, Feb 12, 2017 at 9:05 PM, stephenconnolly [via Maven] <
> > ml-node+s40175n5898384...@n5.nabble.com 
> > (mailto:ml-node+s40175n5898384...@n5.nabble.com)> wrote:
> >  
> > > Can you pop on HipChat with infra?
> > >  
> > > You may need them to grab the files from the agent for you (or modify the
> > > Jenkinsfile temporarily to archive the bits you need)
> > >  
> > > On Sun 12 Feb 2017 at 19:55, Tibor Digana <[hidden email]
> > > > wrote:
> > >  
> > > > There is build process for surefire
> > > >  
> > > > https://builds.apache.org/view/Maven/job/maven-master-
> > > release-status-test-surefire-linux
> > > > with Jenkins file.
> > > > This particular build fails with test
> > > >  
> > > > Surefire141PluggableProvidersIT
> > > >  
> > > > It is only one and different from your local build result.
> > > >  
> > > > I asked Stephen to enable Workspace, because I need to have files from
> > > > target folders for analysis to understand what is going on the machine.
> > > > Stephen told me that I should trigger rebuild. So I did and launched
> > > >  
> > >  
> > > "Build
> > > > with Parameters" but the build failed not running Maven build, however
> > > > Workspace appears now.
> > > >  
> > > > How can I force trigger the build?
> > > >  
> > > >  
> > > > https://builds.apache.org/view/Maven/job/maven-master-
> > > release-status-test-surefire-linux/11/console
> > > >  
> > > > There is another build process, old one actually, and it is successful.
> > > > The difference is because I think race condition when JVM error once
> > > >  
> > >  
> > > goes
> > > > to std/err and other log in the first build with Jenkins file.
> > > > This can, I think, be only one more assertion statement in IT but I need
> > > >  
> > >  
> > > to
> > > > see Workspace.
> > > >  
> > > >  
> > > >  
> > > >  
> > > >  
> > > > On Sun, Feb 12, 2017 at 5:04 PM, Christian Schulte [via Maven] <
> > > > [hidden email] >
> > > >  
> > >  
> > > wrote:
> > > >  
> > > > > @Stephen: Are there any Jenkins jobs left running the plugin ITs with
> > > > > current Maven master? Surefire has it's own git repository. Do we have
> > > > > some Jenkins job for this as well? It's important to run all those ITs
> > > > > (plugins from subversion and the ones with theire own repository) with
> > > > > what we are going to release as 3.5.0 before releasing it.
> > > > >  
> > > > > Regards,
> > > > > --
> > > > > Christian
> > > > >  
> > > > >  
> > > > > -
> > > > > 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/I-think-we-are-ready-for-
> > > > >  
> > > >  
> > >  
> > > 3-5-0-alpha-1-
> > > > > tp5897626p5898337.html
> > > > > To start a new topic under Maven Developers, email
> > > > > [hidden email] 
> > > > > To unsubscribe from Maven Developers, click here
> > > > > <
> > > > >  
> > > > > .
> > > > > NAML
> > > > > <
> > > > >  
> > > >  
> > > > http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?
> > > >  
> > >  
> > >

Re: I think we are ready for 3.5.0-alpha-1

git bisect is pointing to the following commit:

https://github.com/apache/maven/commit/ca4303031357a7decaee8de770b71fb2c2fedd28

if I revert this change then the wrong PID issue disappears and ForkModeIT 
passes again

I suspect that reversing the whole array of system property definitions, while 
solving MNG-6078, is breaking precedence of arguments on the CLI (which then 
affects these tests) 

On Sunday, 12 February 2017 at 20:26, Tibor Digana wrote:

> So this is a local build status of surefire running on the top of certain
> Maven Version.
> Maven 3.3.9 OK on my side
> Maven 3.5.0-SNAPSHOT failed. Wrong PIDs, other tests failed on freebsd and
> not on Win7, so I asked Michael for logs which I do not have.
> So I am going to investigate.
> 
> On Sun, Feb 12, 2017 at 9:05 PM, stephenconnolly [via Maven] <
> ml-node+s40175n5898384...@n5.nabble.com 
> (mailto:ml-node+s40175n5898384...@n5.nabble.com)> wrote:
> 
> > Can you pop on HipChat with infra?
> > 
> > You may need them to grab the files from the agent for you (or modify the
> > Jenkinsfile temporarily to archive the bits you need)
> > 
> > On Sun 12 Feb 2017 at 19:55, Tibor Digana <[hidden email]
> > > wrote:
> > 
> > > There is build process for surefire
> > > 
> > > https://builds.apache.org/view/Maven/job/maven-master-
> > release-status-test-surefire-linux
> > > with Jenkins file.
> > > This particular build fails with test
> > > 
> > > Surefire141PluggableProvidersIT
> > > 
> > > It is only one and different from your local build result.
> > > 
> > > I asked Stephen to enable Workspace, because I need to have files from
> > > target folders for analysis to understand what is going on the machine.
> > > Stephen told me that I should trigger rebuild. So I did and launched
> > > 
> > 
> > "Build
> > > with Parameters" but the build failed not running Maven build, however
> > > Workspace appears now.
> > > 
> > > How can I force trigger the build?
> > > 
> > > 
> > > https://builds.apache.org/view/Maven/job/maven-master-
> > release-status-test-surefire-linux/11/console
> > > 
> > > There is another build process, old one actually, and it is successful.
> > > The difference is because I think race condition when JVM error once
> > > 
> > 
> > goes
> > > to std/err and other log in the first build with Jenkins file.
> > > This can, I think, be only one more assertion statement in IT but I need
> > > 
> > 
> > to
> > > see Workspace.
> > > 
> > > 
> > > 
> > > 
> > > 
> > > On Sun, Feb 12, 2017 at 5:04 PM, Christian Schulte [via Maven] <
> > > [hidden email] >
> > > 
> > 
> > wrote:
> > > 
> > > > @Stephen: Are there any Jenkins jobs left running the plugin ITs with
> > > > current Maven master? Surefire has it's own git repository. Do we have
> > > > some Jenkins job for this as well? It's important to run all those ITs
> > > > (plugins from subversion and the ones with theire own repository) with
> > > > what we are going to release as 3.5.0 before releasing it.
> > > > 
> > > > Regards,
> > > > --
> > > > Christian
> > > > 
> > > > 
> > > > -
> > > > 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/I-think-we-are-ready-for-
> > > > 
> > > 
> > 
> > 3-5-0-alpha-1-
> > > > tp5897626p5898337.html
> > > > To start a new topic under Maven Developers, email
> > > > [hidden email] 
> > > > To unsubscribe from Maven Developers, click here
> > > > <
> > > > 
> > > > .
> > > > NAML
> > > > <
> > > > 
> > > 
> > > http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?
> > > 
> > 
> > macro=macro_viewer=instant_html%21nabble%3Aemail.naml&
> > base=nabble.naml.namespaces.BasicNamespace-nabble.view.
> > web.template.NabbleNamespace-nabble.view.web.template 
> > (http://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:
> > > http://maven.40175.n5.nabble.com/I-think-we-are-ready-for-3-5-0-alpha-1-
> > > 
> > 
> > tp5897626p5898378.html
> > > Sent from the Maven Developers mailing list archive at Nabble.com 
> > > (http://Nabble.com).
> > 
> > 
> > --
> > Sent from my phone
> > 
> > 
> > --
> > If you reply to this email, your message will be added to the discussion
> > below:
> >

Re: I think we are ready for 3.5.0-alpha-1

Build has run. Results are: Core ITs ran successfully. Plugin ITs
failed. Surefire build failed. Workspaces are here:



Apache Maven Remote Resources Plugin ... FAILURE

/bin/sh: 1: mvn: not found

Maybe a launcher issue?



Same on Windows.

'mvn' is not recognized as an internal or external command,
operable program or batch file.

I'll take a look tomorrow.



Looking at the console output, this pretty much looks the same as what I
am getting locally:





Windows seems to be affected as well. Console output is here:



The easiest way to trigger all those jobs is to start the following
build job:



This will trigger all the other build jobs in correct order.

Note: I setup those jobs during working on the pre-reset-master branch
when I noticed that it's not enough to just run the core ITs. Those jobs
never succeeded since I created them. That's what I was working on
before resetting the branches. I would not have exepected those jobs to
fail after the reset.

The maven-master-release-status job is setup to run once a week. It is
this job sending those [PING] subject mails every now and then. When all
jobs succeed, it would (hopefully) send a mail stating that master is in
a releaseable state.

Regards,
-- 
Christian


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

Re: I think we are ready for 3.5.0-alpha-1

Am 12.02.2017 um 20:54 schrieb Tibor Digana:
> There is build process for surefire
> https://builds.apache.org/view/Maven/job/maven-master-release-status-test-surefire-linux
> with Jenkins file.
> This particular build fails with test
> 
> Surefire141PluggableProvidersIT
> 
> It is only one and different from your local build result.
> 
> I asked Stephen to enable Workspace, because I need to have files from
> target folders for analysis to understand what is going on the machine.
> Stephen told me that I should trigger rebuild. So I did and launched "Build
> with Parameters" but the build failed not running Maven build, however
> Workspace appears now.
> 
> How can I force trigger the build?

This is my amateur trial and error pseudo-pipeline setup. You can
trigger that "pipeline" by starting an initial build job here. This will
trigger all the other jobs.



I just started a build. If you login to Jenkins, you should be able to
access the different workspaces. Maybe a permission issue. Just login
and the workspace should be there.

Regards,
-- 
Christian


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

Re: I think we are ready for 3.5.0-alpha-1

I never checked different Maven versions or Surefire tags. Only the
pre-reset-master branch for a few weeks (3.4.0-SNAPSHOT back then) and
now with current Maven master (3.5.0-SNAPSHOT). The only changes to the
Maven core which could have an impact to multi-threading behaviour can
be some dependency upgrade introducing issues. We maybe just need to
find out which dependency upgrade introduces the issues. Plexus comes to
mind.


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

Re: I think we are ready for 3.5.0-alpha-1

So this is a local build status of surefire running on the top of certain
Maven Version.
Maven 3.3.9 OK on my side
Maven 3.5.0-SNAPSHOT failed. Wrong PIDs, other tests failed on freebsd and
not on Win7, so I asked Michael for logs which I do not have.
So I am going to investigate.

On Sun, Feb 12, 2017 at 9:05 PM, stephenconnolly [via Maven] <
ml-node+s40175n5898384...@n5.nabble.com> wrote:

> Can you pop on HipChat with infra?
>
> You may need them to grab the files from the agent for you (or modify the
> Jenkinsfile temporarily to archive the bits you need)
>
> On Sun 12 Feb 2017 at 19:55, Tibor Digana <[hidden email]
> > wrote:
>
> > There is build process for surefire
> >
> > https://builds.apache.org/view/Maven/job/maven-master-
> release-status-test-surefire-linux
> > with Jenkins file.
> > This particular build fails with test
> >
> > Surefire141PluggableProvidersIT
> >
> > It is only one and different from your local build result.
> >
> > I asked Stephen to enable Workspace, because I need to have files from
> > target folders for analysis to understand what is going on the machine.
> > Stephen told me that I should trigger rebuild. So I did and launched
> "Build
> > with Parameters" but the build failed not running Maven build, however
> > Workspace appears now.
> >
> > How can I force trigger the build?
> >
> >
> > https://builds.apache.org/view/Maven/job/maven-master-
> release-status-test-surefire-linux/11/console
> >
> > There is another build process, old one actually, and it is successful.
> > The difference is because I think race condition when JVM error once
> goes
> > to std/err and other log in the first build with Jenkins file.
> > This can, I think, be only one more assertion statement in IT but I need
> to
> > see Workspace.
> >
> >
> >
> >
> >
> > On Sun, Feb 12, 2017 at 5:04 PM, Christian Schulte [via Maven] <
> > [hidden email] >
> wrote:
> >
> > > @Stephen: Are there any Jenkins jobs left running the plugin ITs with
> > > current Maven master? Surefire has it's own git repository. Do we have
> > > some Jenkins job for this as well? It's important to run all those ITs
> > > (plugins from subversion and the ones with theire own repository) with
> > > what we are going to release as 3.5.0 before releasing it.
> > >
> > > Regards,
> > > --
> > > Christian
> > >
> > >
> > > -
> > > 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/I-think-we-are-ready-for-
> 3-5-0-alpha-1-
> > > tp5897626p5898337.html
> > > To start a new topic under Maven Developers, email
> > > [hidden email] 
> > > To unsubscribe from Maven Developers, click here
> > > <
> > >
> > > .
> > > NAML
> > > <
> > http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?
> 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:
> > http://maven.40175.n5.nabble.com/I-think-we-are-ready-for-3-5-0-alpha-1-
> tp5897626p5898378.html
> > Sent from the Maven Developers mailing list archive at Nabble.com.
>
> --
> Sent from my phone
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://maven.40175.n5.nabble.com/I-think-we-are-ready-for-3-5-0-alpha-1-
> tp5897626p5898384.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/I-think-we-are-ready-for-3-5-0-alpha-1-tp5897626p5898389.html
Sent from the Maven Developers mailing list archive at Nabble.com.

Re: I think we are ready for 3.5.0-alpha-1

2017-02-12 Thread Stephen Connolly

Can you pop on HipChat with infra?

You may need them to grab the files from the agent for you (or modify the
Jenkinsfile temporarily to archive the bits you need)

On Sun 12 Feb 2017 at 19:55, Tibor Digana  wrote:

> There is build process for surefire
>
> https://builds.apache.org/view/Maven/job/maven-master-release-status-test-surefire-linux
> with Jenkins file.
> This particular build fails with test
>
> Surefire141PluggableProvidersIT
>
> It is only one and different from your local build result.
>
> I asked Stephen to enable Workspace, because I need to have files from
> target folders for analysis to understand what is going on the machine.
> Stephen told me that I should trigger rebuild. So I did and launched "Build
> with Parameters" but the build failed not running Maven build, however
> Workspace appears now.
>
> How can I force trigger the build?
>
>
> https://builds.apache.org/view/Maven/job/maven-master-release-status-test-surefire-linux/11/console
>
> There is another build process, old one actually, and it is successful.
> The difference is because I think race condition when JVM error once goes
> to std/err and other log in the first build with Jenkins file.
> This can, I think, be only one more assertion statement in IT but I need to
> see Workspace.
>
>
>
>
>
> On Sun, Feb 12, 2017 at 5:04 PM, Christian Schulte [via Maven] <
> ml-node+s40175n5898337...@n5.nabble.com> wrote:
>
> > @Stephen: Are there any Jenkins jobs left running the plugin ITs with
> > current Maven master? Surefire has it's own git repository. Do we have
> > some Jenkins job for this as well? It's important to run all those ITs
> > (plugins from subversion and the ones with theire own repository) with
> > what we are going to release as 3.5.0 before releasing it.
> >
> > Regards,
> > --
> > Christian
> >
> >
> > -
> > 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/I-think-we-are-ready-for-3-5-0-alpha-1-
> > tp5897626p5898337.html
> > To start a new topic under Maven Developers, email
> > ml-node+s40175n142166...@n5.nabble.com
> > To unsubscribe from Maven Developers, click here
> > <
> http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code=142166=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg==
> >
> > .
> > NAML
> > <
> http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer=instant_html%21nabble%3Aemail.naml=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:
> http://maven.40175.n5.nabble.com/I-think-we-are-ready-for-3-5-0-alpha-1-tp5897626p5898378.html
> Sent from the Maven Developers mailing list archive at Nabble.com.

-- 
Sent from my phone

Re: I think we are ready for 3.5.0-alpha-1

There is build process for surefire
https://builds.apache.org/view/Maven/job/maven-master-release-status-test-surefire-linux
with Jenkins file.
This particular build fails with test

Surefire141PluggableProvidersIT

It is only one and different from your local build result.

I asked Stephen to enable Workspace, because I need to have files from
target folders for analysis to understand what is going on the machine.
Stephen told me that I should trigger rebuild. So I did and launched "Build
with Parameters" but the build failed not running Maven build, however
Workspace appears now.

How can I force trigger the build?

https://builds.apache.org/view/Maven/job/maven-master-release-status-test-surefire-linux/11/console

There is another build process, old one actually, and it is successful.
The difference is because I think race condition when JVM error once goes
to std/err and other log in the first build with Jenkins file.
This can, I think, be only one more assertion statement in IT but I need to
see Workspace.

On Sun, Feb 12, 2017 at 5:04 PM, Christian Schulte [via Maven] <
ml-node+s40175n5898337...@n5.nabble.com> wrote:

> @Stephen: Are there any Jenkins jobs left running the plugin ITs with
> current Maven master? Surefire has it's own git repository. Do we have
> some Jenkins job for this as well? It's important to run all those ITs
> (plugins from subversion and the ones with theire own repository) with
> what we are going to release as 3.5.0 before releasing it.
>
> Regards,
> --
> Christian
>
>
> -
> 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/I-think-we-are-ready-for-3-5-0-alpha-1-
> tp5897626p5898337.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/I-think-we-are-ready-for-3-5-0-alpha-1-tp5897626p5898378.html
Sent from the Maven Developers mailing list archive at Nabble.com.

Re: I think we are ready for 3.5.0-alpha-1

@Stephen: Are there any Jenkins jobs left running the plugin ITs with
current Maven master? Surefire has it's own git repository. Do we have
some Jenkins job for this as well? It's important to run all those ITs
(plugins from subversion and the ones with theire own repository) with
what we are going to release as 3.5.0 before releasing it.

Regards,
-- 
Christian


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

Re: I think we are ready for 3.5.0-alpha-1

This is what happens when building (mvn verify -X -l surefire.log) the
2.19.1 tag with current Maven master.

Failed tests:
testForkModeOncePerThreadSingleThread(org.apache.maven.surefire.its.ForkModeTestNGIT):
pid 1 didn't match pid 2 expected:<[18462]@t60.schulte.it test...> but
was:<[55738]@t60.schulte.it test...>

testForkModeOncePerThreadTwoThreads(org.apache.maven.surefire.its.ForkModeTestNGIT):
number of different pids is not as expected expected:<2> but was:<3>

testSecurityManager(org.apache.maven.surefire.its.jiras.Surefire34SecurityManagerIT):
wrong number of errors expected:<1> but was:<0>

shouldNotBeVerbose(org.apache.maven.surefire.its.CheckTestNgReportTestIT):
log pattern does not match nTimes(..)

testForkModeOncePerThreadSingleThread(org.apache.maven.surefire.its.ForkModeIT):
pid 1 didn't match pid 2 expected:<[48251]@t60.schulte.it test...> but
was:<[52396]@t60.schulte.it test...>

testForkModeOncePerThreadTwoThreads(org.apache.maven.surefire.its.ForkModeIT):
number of different pids is not as expected expected:<2> but was:<3>

I'll send the log file in a separate private mail. It's nearly 1MB of
size (gzipped).

Regards,
-- 
Christian



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

Re: I think we are ready for 3.5.0-alpha-1

2017-02-12 Thread Michael Osipov


Am 2017-02-12 um 13:45 schrieb Christian Schulte:

Am 02/12/17 um 11:29 schrieb Michael Osipov:

Am 2017-02-12 um 06:53 schrieb Tibor Digana:

What surefire tag exactly?


I know understand what he wants now, use Maven 3.3.9/3.5.0-SNAPSHOT and
build 2.12.4 and 2.19.1 (default-bindings.xml) on FreeBSD with OpenJDK 7.


Yes. Just 2.19.1. Can you build that tag on FreeBSD successfully. I am
getting IT failures. That's why I started to look into surefire. Haven't
checked 2.12.4, though. Will do that now.


This is what I have:

Test 1 (3.3.9, both tags):
===

[mosipov@bsd10 ~/Projekte/maven-surefire]$ mvn -v
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
2015-11-10T17:41:47+01:00)
Maven home: /usr/local/apache-maven-3.3.9
Java version: 1.7.0_111, vendor: Oracle Corporation
Java home: /usr/local/openjdk7/jre
Default locale: de_DE, platform encoding: UTF-8
OS name: "freebsd", version: "10.3-release-p11", arch: "amd64", family: "unix"
[mosipov@bsd10 ~/Projekte/maven-surefire]$ git branch
* (HEAD losgelöst bei surefire-2.19.1)
  master
[mosipov@bsd10 ~/Projekte/maven-surefire]$ mvn clean verify -Prun-its
...
[INFO] Maven Surefire Integration Tests ... SUCCESS [  01:24 h]
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 01:33 h
[INFO] Finished at: 2017-02-12T13:07:40+01:00
[INFO] Final Memory: 51M/212M
[INFO] 
[mosipov@bsd10 ~/Projekte/maven-surefire]$ git branch
* (HEAD losgelöst bei surefire-2.12.4)
  master
[mosipov@bsd10 ~/Projekte/maven-surefire]$ mvn clean verify -Prun-its
[INFO] --- maven-surefire-plugin:2.12:test (default-test) @ surefire-api ---
[INFO] Surefire report directory: 
/usr/home/mosipov/Projekte/maven-surefire/surefire-api/target/surefire-reports
[INFO] Using configured provider org.apache.maven.surefire.junit.JUnit3Provider
[INFO] Using configured provider 
org.apache.maven.surefire.shadefire.junit.JUnit3Provider

---
 T E S T S
---
Fehler: Hauptklasse org.apache.maven.surefire.booter.ForkedBooter konnte nicht 
gefunden oder geladen werden

Results :

Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

[INFO] Maven Surefire Integration Tests ... SKIPPED
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 11.366 s
[INFO] Finished at: 2017-02-12T13:23:37+01:00
[INFO] Final Memory: 24M/58M
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-surefire-plugin:2.12:test (default-test) on project 
surefire-api: Error occurred in starting fork, check output in log -> [Help 1]

===

Test 2 (3.5.0-SNAPSHOT from MNG-6169, both tags):
===

[mosipov@bsd10 ~/Projekte/maven-surefire]$ git branch
* (HEAD losgelöst bei surefire-2.12.4)
  master
[mosipov@bsd10 ~/Projekte/maven-surefire]$ 
~/apache-maven-3.5.0-SNAPSHOT/bin/mvn clean verify -Prun-its
[INFO] Using configured provider 
org.apache.maven.surefire.shadefire.junit.JUnit3Provider

---
 T E S T S
---
Fehler: Hauptklasse org.apache.maven.surefire.booter.ForkedBooter konnte nicht 
gefunden oder geladen werden

Results :

Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
[INFO] Maven Surefire Integration Tests ... SKIPPED
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 11.879 s
[INFO] Finished at: 2017-02-12T13:44:38+01:00
[INFO] Final Memory: 22M/53M
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-surefire-plugin:2.12:test (default-test) on project 
surefire-api: Error occurred in starting fork, check output in log -> [Help 1]
[mosipov@bsd10 ~/Projekte/maven-surefire]$ git branch
* (HEAD losgelöst bei surefire-2.19.1)
  master
[mosipov@bsd10 ~/Projekte/maven-surefire]$ 
~/apache-maven-3.5.0-SNAPSHOT/bin/mvn clean verify -Prun-its
Failed tests:   
testForkModeOncePerThreadSingleThread(org.apache.maven.surefire.its.ForkModeTestNGIT): pid 
1 didn't match pid 2 expected:<111[70]@bsd10.local testVal...> but 
was:<111[69]@bsd10.local testVal...>

Re: I think we are ready for 3.5.0-alpha-1

Am 02/12/17 um 11:29 schrieb Michael Osipov:
> Am 2017-02-12 um 06:53 schrieb Tibor Digana:
>> What surefire tag exactly?
> 
> I know understand what he wants now, use Maven 3.3.9/3.5.0-SNAPSHOT and 
> build 2.12.4 and 2.19.1 (default-bindings.xml) on FreeBSD with OpenJDK 7.

Yes. Just 2.19.1. Can you build that tag on FreeBSD successfully. I am
getting IT failures. That's why I started to look into surefire. Haven't
checked 2.12.4, though. Will do that now.


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

Re: I think we are ready for 3.5.0-alpha-1

2017-02-12 Thread Michael Osipov

Am 2017-02-12 um 06:53 schrieb Tibor Digana:

What surefire tag exactly?

I know understand what he wants now, use Maven 3.3.9/3.5.0-SNAPSHOT and
build 2.12.4 and 2.19.1 (default-bindings.xml) on FreeBSD with OpenJDK 7.

On Sun, Feb 12, 2017 at 1:56 AM, Christian Schulte [via Maven] <
ml-node+s40175n5898195...@n5.nabble.com> wrote:

Am 02/12/17 um 00:59 schrieb Michael Osipov:

Am 2017-02-12 um 00:49 schrieb Christian Schulte:

Am 02/11/17 um 23:03 schrieb Michael Osipov:

The lifecylce plugins have been moved to MNG-6169. MPLUGIN has been
retained with 3.3 because there were failures. One IT is failing,
MNG-5572. I am looking into the cause right now.

Out of curiosity. @Michael: Do you have a FreeBSD box or something else
BSD at hand? Can you build the surefire tag of that version locally
without any issues? I am getting IT failures on OpenBSD here. On

Jenkins

nothing is failing. Would be interesting how that looks on FreeBSD.

Yes, sure. FreeBSD is my main Unix test platform. So you want me to run
ITs with MNG-6169, is that right?

No. A surefire build of the tag corresponding to the version in core.
That build will run various surefire related ITs. Can you build that
surefire tag successfully?

-
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/I-think-we-are-ready-for-3-5-0-alpha-1-
tp5897626p5898195.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/I-think-we-are-ready-for-3-5-0-alpha-1-tp5897626p5898200.html
Sent from the Maven Developers mailing list archive at Nabble.com.

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

Re: I think we are ready for 3.5.0-alpha-1

2017-02-11 Thread Tibor Digana

What surefire tag exactly?

On Sun, Feb 12, 2017 at 1:56 AM, Christian Schulte [via Maven] <
ml-node+s40175n5898195...@n5.nabble.com> wrote:

> Am 02/12/17 um 00:59 schrieb Michael Osipov:
>
> > Am 2017-02-12 um 00:49 schrieb Christian Schulte:
> >> Am 02/11/17 um 23:03 schrieb Michael Osipov:
> >>> The lifecylce plugins have been moved to MNG-6169. MPLUGIN has been
> >>> retained with 3.3 because there were failures. One IT is failing,
> >>> MNG-5572. I am looking into the cause right now.
> >>
> >> Out of curiosity. @Michael: Do you have a FreeBSD box or something else
> >> BSD at hand? Can you build the surefire tag of that version locally
> >> without any issues? I am getting IT failures on OpenBSD here. On
> Jenkins
> >> nothing is failing. Would be interesting how that looks on FreeBSD.
> >
> > Yes, sure. FreeBSD is my main Unix test platform. So you want me to run
> > ITs with MNG-6169, is that right?
>
> No. A surefire build of the tag corresponding to the version in core.
> That build will run various surefire related ITs. Can you build that
> surefire tag successfully?
>
>
> -
> 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/I-think-we-are-ready-for-3-5-0-alpha-1-
> tp5897626p5898195.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/I-think-we-are-ready-for-3-5-0-alpha-1-tp5897626p5898200.html
Sent from the Maven Developers mailing list archive at Nabble.com.

Re: I think we are ready for 3.5.0-alpha-1

Am 02/12/17 um 00:59 schrieb Michael Osipov:
> Am 2017-02-12 um 00:49 schrieb Christian Schulte:
>> Am 02/11/17 um 23:03 schrieb Michael Osipov:
>>> The lifecylce plugins have been moved to MNG-6169. MPLUGIN has been
>>> retained with 3.3 because there were failures. One IT is failing,
>>> MNG-5572. I am looking into the cause right now.
>>
>> Out of curiosity. @Michael: Do you have a FreeBSD box or something else
>> BSD at hand? Can you build the surefire tag of that version locally
>> without any issues? I am getting IT failures on OpenBSD here. On Jenkins
>> nothing is failing. Would be interesting how that looks on FreeBSD.
> 
> Yes, sure. FreeBSD is my main Unix test platform. So you want me to run 
> ITs with MNG-6169, is that right?

No. A surefire build of the tag corresponding to the version in core.
That build will run various surefire related ITs. Can you build that
surefire tag successfully?


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

Re: I think we are ready for 3.5.0-alpha-1


Am 2017-02-12 um 00:49 schrieb Christian Schulte:

Am 02/11/17 um 23:03 schrieb Michael Osipov:

The lifecylce plugins have been moved to MNG-6169. MPLUGIN has been
retained with 3.3 because there were failures. One IT is failing,
MNG-5572. I am looking into the cause right now.


Out of curiosity. @Michael: Do you have a FreeBSD box or something else
BSD at hand? Can you build the surefire tag of that version locally
without any issues? I am getting IT failures on OpenBSD here. On Jenkins
nothing is failing. Would be interesting how that looks on FreeBSD.


Yes, sure. FreeBSD is my main Unix test platform. So you want me to run 
ITs with MNG-6169, is that right?



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

Re: I think we are ready for 3.5.0-alpha-1

Am 02/11/17 um 23:03 schrieb Michael Osipov:
> The lifecylce plugins have been moved to MNG-6169. MPLUGIN has been 
> retained with 3.3 because there were failures. One IT is failing, 
> MNG-5572. I am looking into the cause right now.

Out of curiosity. @Michael: Do you have a FreeBSD box or something else
BSD at hand? Can you build the surefire tag of that version locally
without any issues? I am getting IT failures on OpenBSD here. On Jenkins
nothing is failing. Would be interesting how that looks on FreeBSD.

Regards,
-- 
Christian


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

Re: I think we are ready for 3.5.0-alpha-1

Am 02/11/17 um 23:03 schrieb Michael Osipov:
> Am 2017-02-11 um 18:23 schrieb Christian Schulte:
>> Am 02/11/17 um 18:20 schrieb Michael Osipov:
>>> Am 2017-02-11 um 18:08 schrieb Christian Schulte:
 Am 02/08/17 um 21:14 schrieb Michael Osipov:
> Am 2017-02-08 um 21:01 schrieb Stephen Connolly:
>> I think all the important stuff is merged. I'll take a final review 
>> through
>> and then cut alpha-1
>>
>> We can still add stuff if necessary for an alpha-2 but I'd much prefer to
>> focus that on shaking out bugs.
>>
>> Ideally we do at most 3 alpha's before soft-code-freeze and a beta (at
>> which point it should only be serious bug fixes)
>>
>> Then we give the beta some soak and cut the release
>>
>> I toyed with spinning RCs but I'm thinking alpha and beta are better 
>> terms
>
> Looks good to me. I think that the very first alpha should also include
> MNG-5967 Dependency updates
> MNG-5968 Default plugin version updates
   ^
 This has a huge impact on the ITs. Last time I checked there has not
 been a maven-plugin-plugin version around we could have upgraded to.
 Let's postpone this until all plugins referenced by the core can be
 upgraded to Maven 3.0 prerequisites. Someone knows what plugins are
 still in need to be bumped to Maven 3?
>>>
>>> I haven't merged them yet and won't without any. I plan to split this
>>> ticket up to three.
>>>
>>> What is the impact going to be if all ITs pass? MPLUGIN 3.5 has already
>>> been released and you fixed an issue stopped us from upgrading to 3.5.
>>
>> Last time I wanted to upgrade the maven-plugin-plugin in the Maven
>> parent, Robert asked me to revert due to an outstanding issue with 3.5.
>> Are you sure the ITs are running with that plugin version? You'll need
>> to update a lot of plugin sources in the ITs to add missing Javadoc
>> descriptions everyhwere. Without that, the IT plugins cannot be build.
> 
> MNG-5968 has been drastically reduced to trivial updates. It been split 
> as agreed with Robert. ITs pass. Waiting for an argeement for FIx-3.5.0.

It's just updating some plugins used to build Maven itself. No need to
ask for anything here. If Maven can be build without issues, no need to
ask anyone for confirmation, IMHO. FIX-3.5.0 seconded.

> 
> The lifecylce plugins have been moved to MNG-6169. MPLUGIN has been 
> retained with 3.3 because there were failures. One IT is failing, 
> MNG-5572. I am looking into the cause right now.

I am running into issues with recent surefire versions sporadically.
Maybe we better keep the default version unchanged or we risk JIRA
issues to be filed. Maybe not that bad. Let's see if others are running
into the same surefire issues I am running into.

Someone already verified there are no open blocker issues filed in JIRA
for the new default plugin versions? Should I do that?

Regards,
-- 
Christian


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

Re: I think we are ready for 3.5.0-alpha-1


Am 2017-02-11 um 18:19 schrieb Christian Schulte:

Am 02/08/17 um 21:14 schrieb Michael Osipov:

Am 2017-02-08 um 21:01 schrieb Stephen Connolly:

I think all the important stuff is merged. I'll take a final review through
and then cut alpha-1

We can still add stuff if necessary for an alpha-2 but I'd much prefer to
focus that on shaking out bugs.

Ideally we do at most 3 alpha's before soft-code-freeze and a beta (at
which point it should only be serious bug fixes)

Then we give the beta some soak and cut the release

I toyed with spinning RCs but I'm thinking alpha and beta are better terms


Looks good to me. I think that the very first alpha should also include
MNG-5967 Dependency updates
MNG-5968 Default plugin version updates

  ^
Not sure about it. Surefire plugin should not be upgraded, IMHO. For the
site plugin upgrade, the site.xml descriptors need updating, AFAIK. Are
the site.xml descriptors prepared for that plugin version already?


I now ran MNG-6169 on master with "mvn site -Preporting". It did without 
failures, though it consumes a lot of memory and Javadoc in classes has 
a lot of issues.


Michael


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

Re: I think we are ready for 3.5.0-alpha-1


Am 2017-02-11 um 18:23 schrieb Christian Schulte:

Am 02/11/17 um 18:20 schrieb Michael Osipov:

Am 2017-02-11 um 18:08 schrieb Christian Schulte:

Am 02/08/17 um 21:14 schrieb Michael Osipov:

Am 2017-02-08 um 21:01 schrieb Stephen Connolly:

I think all the important stuff is merged. I'll take a final review through
and then cut alpha-1

We can still add stuff if necessary for an alpha-2 but I'd much prefer to
focus that on shaking out bugs.

Ideally we do at most 3 alpha's before soft-code-freeze and a beta (at
which point it should only be serious bug fixes)

Then we give the beta some soak and cut the release

I toyed with spinning RCs but I'm thinking alpha and beta are better terms


Looks good to me. I think that the very first alpha should also include
MNG-5967 Dependency updates
MNG-5968 Default plugin version updates

  ^
This has a huge impact on the ITs. Last time I checked there has not
been a maven-plugin-plugin version around we could have upgraded to.
Let's postpone this until all plugins referenced by the core can be
upgraded to Maven 3.0 prerequisites. Someone knows what plugins are
still in need to be bumped to Maven 3?


I haven't merged them yet and won't without any. I plan to split this
ticket up to three.

What is the impact going to be if all ITs pass? MPLUGIN 3.5 has already
been released and you fixed an issue stopped us from upgrading to 3.5.


Last time I wanted to upgrade the maven-plugin-plugin in the Maven
parent, Robert asked me to revert due to an outstanding issue with 3.5.
Are you sure the ITs are running with that plugin version? You'll need
to update a lot of plugin sources in the ITs to add missing Javadoc
descriptions everyhwere. Without that, the IT plugins cannot be build.


MNG-5968 has been drastically reduced to trivial updates. It been split 
as agreed with Robert. ITs pass. Waiting for an argeement for FIx-3.5.0.


The lifecylce plugins have been moved to MNG-6169. MPLUGIN has been 
retained with 3.3 because there were failures. One IT is failing, 
MNG-5572. I am looking into the cause right now.


Michael


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

Re: I think we are ready for 3.5.0-alpha-1


Am 2017-02-11 um 18:23 schrieb Christian Schulte:

Am 02/11/17 um 18:20 schrieb Michael Osipov:

Am 2017-02-11 um 18:08 schrieb Christian Schulte:

Am 02/08/17 um 21:14 schrieb Michael Osipov:

Am 2017-02-08 um 21:01 schrieb Stephen Connolly:

I think all the important stuff is merged. I'll take a final review through
and then cut alpha-1

We can still add stuff if necessary for an alpha-2 but I'd much prefer to
focus that on shaking out bugs.

Ideally we do at most 3 alpha's before soft-code-freeze and a beta (at
which point it should only be serious bug fixes)

Then we give the beta some soak and cut the release

I toyed with spinning RCs but I'm thinking alpha and beta are better terms


Looks good to me. I think that the very first alpha should also include
MNG-5967 Dependency updates
MNG-5968 Default plugin version updates

  ^
This has a huge impact on the ITs. Last time I checked there has not
been a maven-plugin-plugin version around we could have upgraded to.
Let's postpone this until all plugins referenced by the core can be
upgraded to Maven 3.0 prerequisites. Someone knows what plugins are
still in need to be bumped to Maven 3?


I haven't merged them yet and won't without any. I plan to split this
ticket up to three.

What is the impact going to be if all ITs pass? MPLUGIN 3.5 has already
been released and you fixed an issue stopped us from upgrading to 3.5.


Last time I wanted to upgrade the maven-plugin-plugin in the Maven
parent, Robert asked me to revert due to an outstanding issue with 3.5.
Are you sure the ITs are running with that plugin version? You'll need
to update a lot of plugin sources in the ITs to add missing Javadoc
descriptions everyhwere. Without that, the IT plugins cannot be build.


I see what you are after, I will simply prepare a branch and we'll see 
wether this works at all. No obligations.


Michael


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

Re: I think we are ready for 3.5.0-alpha-1

Am 02/11/17 um 18:20 schrieb Michael Osipov:
> Am 2017-02-11 um 18:08 schrieb Christian Schulte:
>> Am 02/08/17 um 21:14 schrieb Michael Osipov:
>>> Am 2017-02-08 um 21:01 schrieb Stephen Connolly:
 I think all the important stuff is merged. I'll take a final review through
 and then cut alpha-1

 We can still add stuff if necessary for an alpha-2 but I'd much prefer to
 focus that on shaking out bugs.

 Ideally we do at most 3 alpha's before soft-code-freeze and a beta (at
 which point it should only be serious bug fixes)

 Then we give the beta some soak and cut the release

 I toyed with spinning RCs but I'm thinking alpha and beta are better terms
>>>
>>> Looks good to me. I think that the very first alpha should also include
>>> MNG-5967 Dependency updates
>>> MNG-5968 Default plugin version updates
>>   ^
>> This has a huge impact on the ITs. Last time I checked there has not
>> been a maven-plugin-plugin version around we could have upgraded to.
>> Let's postpone this until all plugins referenced by the core can be
>> upgraded to Maven 3.0 prerequisites. Someone knows what plugins are
>> still in need to be bumped to Maven 3?
> 
> I haven't merged them yet and won't without any. I plan to split this 
> ticket up to three.
> 
> What is the impact going to be if all ITs pass? MPLUGIN 3.5 has already 
> been released and you fixed an issue stopped us from upgrading to 3.5.

Last time I wanted to upgrade the maven-plugin-plugin in the Maven
parent, Robert asked me to revert due to an outstanding issue with 3.5.
Are you sure the ITs are running with that plugin version? You'll need
to update a lot of plugin sources in the ITs to add missing Javadoc
descriptions everyhwere. Without that, the IT plugins cannot be build.


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

Re: I think we are ready for 3.5.0-alpha-1


Am 2017-02-11 um 18:19 schrieb Christian Schulte:

Am 02/08/17 um 21:14 schrieb Michael Osipov:

Am 2017-02-08 um 21:01 schrieb Stephen Connolly:

I think all the important stuff is merged. I'll take a final review through
and then cut alpha-1

We can still add stuff if necessary for an alpha-2 but I'd much prefer to
focus that on shaking out bugs.

Ideally we do at most 3 alpha's before soft-code-freeze and a beta (at
which point it should only be serious bug fixes)

Then we give the beta some soak and cut the release

I toyed with spinning RCs but I'm thinking alpha and beta are better terms


Looks good to me. I think that the very first alpha should also include
MNG-5967 Dependency updates
MNG-5968 Default plugin version updates

  ^
Not sure about it. Surefire plugin should not be upgraded, IMHO. For the
site plugin upgrade, the site.xml descriptors need updating, AFAIK. Are
the site.xml descriptors prepared for that plugin version already? I'd
say -1 to changing the plugin management in the 4.0.0 super POM. Let's
not touch those versions but remove the whole plugin management in 3.5.1.


I'd rather wait for SUREFIRE 2.19.2. As far as I remember, Hervé and I 
did that, but I will run the site phase again. I am highly +1 on 
removing plugin management from the POM.


Michael



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

Re: I think we are ready for 3.5.0-alpha-1


Am 2017-02-11 um 18:08 schrieb Christian Schulte:

Am 02/08/17 um 21:14 schrieb Michael Osipov:

Am 2017-02-08 um 21:01 schrieb Stephen Connolly:

I think all the important stuff is merged. I'll take a final review through
and then cut alpha-1

We can still add stuff if necessary for an alpha-2 but I'd much prefer to
focus that on shaking out bugs.

Ideally we do at most 3 alpha's before soft-code-freeze and a beta (at
which point it should only be serious bug fixes)

Then we give the beta some soak and cut the release

I toyed with spinning RCs but I'm thinking alpha and beta are better terms


Looks good to me. I think that the very first alpha should also include
MNG-5967 Dependency updates
MNG-5968 Default plugin version updates

  ^
This has a huge impact on the ITs. Last time I checked there has not
been a maven-plugin-plugin version around we could have upgraded to.
Let's postpone this until all plugins referenced by the core can be
upgraded to Maven 3.0 prerequisites. Someone knows what plugins are
still in need to be bumped to Maven 3?


I haven't merged them yet and won't without any. I plan to split this 
ticket up to three.


What is the impact going to be if all ITs pass? MPLUGIN 3.5 has already 
been released and you fixed an issue stopped us from upgrading to 3.5.


Michael


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

Re: I think we are ready for 3.5.0-alpha-1

Am 02/08/17 um 21:14 schrieb Michael Osipov:
> Am 2017-02-08 um 21:01 schrieb Stephen Connolly:
>> I think all the important stuff is merged. I'll take a final review through
>> and then cut alpha-1
>>
>> We can still add stuff if necessary for an alpha-2 but I'd much prefer to
>> focus that on shaking out bugs.
>>
>> Ideally we do at most 3 alpha's before soft-code-freeze and a beta (at
>> which point it should only be serious bug fixes)
>>
>> Then we give the beta some soak and cut the release
>>
>> I toyed with spinning RCs but I'm thinking alpha and beta are better terms
> 
> Looks good to me. I think that the very first alpha should also include
> MNG-5967 Dependency updates
> MNG-5968 Default plugin version updates
  ^
Not sure about it. Surefire plugin should not be upgraded, IMHO. For the
site plugin upgrade, the site.xml descriptors need updating, AFAIK. Are
the site.xml descriptors prepared for that plugin version already? I'd
say -1 to changing the plugin management in the 4.0.0 super POM. Let's
not touch those versions but remove the whole plugin management in 3.5.1.




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

Re: I think we are ready for 3.5.0-alpha-1

Am 02/08/17 um 21:14 schrieb Michael Osipov:
> Am 2017-02-08 um 21:01 schrieb Stephen Connolly:
>> I think all the important stuff is merged. I'll take a final review through
>> and then cut alpha-1
>>
>> We can still add stuff if necessary for an alpha-2 but I'd much prefer to
>> focus that on shaking out bugs.
>>
>> Ideally we do at most 3 alpha's before soft-code-freeze and a beta (at
>> which point it should only be serious bug fixes)
>>
>> Then we give the beta some soak and cut the release
>>
>> I toyed with spinning RCs but I'm thinking alpha and beta are better terms
> 
> Looks good to me. I think that the very first alpha should also include
> MNG-5967 Dependency updates
  ^
+1 to the MNG-5967 branch.


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

Re: I think we are ready for 3.5.0-alpha-1

Am 02/08/17 um 21:14 schrieb Michael Osipov:
> Am 2017-02-08 um 21:01 schrieb Stephen Connolly:
>> I think all the important stuff is merged. I'll take a final review through
>> and then cut alpha-1
>>
>> We can still add stuff if necessary for an alpha-2 but I'd much prefer to
>> focus that on shaking out bugs.
>>
>> Ideally we do at most 3 alpha's before soft-code-freeze and a beta (at
>> which point it should only be serious bug fixes)
>>
>> Then we give the beta some soak and cut the release
>>
>> I toyed with spinning RCs but I'm thinking alpha and beta are better terms
> 
> Looks good to me. I think that the very first alpha should also include
> MNG-5967 Dependency updates
> MNG-5968 Default plugin version updates
  ^
This has a huge impact on the ITs. Last time I checked there has not
been a maven-plugin-plugin version around we could have upgraded to.
Let's postpone this until all plugins referenced by the core can be
upgraded to Maven 3.0 prerequisites. Someone knows what plugins are
still in need to be bumped to Maven 3?


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

Re: I think we are ready for 3.5.0-alpha-1

2017-02-11 Thread Robert Scholte

On Sat, 11 Feb 2017 15:46:37 +0100, Michael Osipov   
wrote:



Am 2017-02-11 um 15:33 schrieb Robert Scholte:

The list of updates should be added to the release notes, I'd say use
the matching JIRA issue.


Do you want me to add these to the issue description itself? Unless I  
create a JIRA issue per dependency, they won't show up in the release  
notes. One could do this with sub-tasks.


No, I don't think there's a need for such detail. It should be easy to  
trace back such changes. So if we have one JIRA with the diff of 3.3.9 and  
3.5.0 that's good enough.





branch of MNG-5967 looks good to me.


Thanks, I will merge when all tests pass.

I have now added a MNG-5968 branch, but I think this needs to be broken  
up into three separate issues:


1. Lifecycle/binding plugin version updates
2. Super POM plugin version updates
3. Default plugin version updates

WDYT?



Makes sense


On Sat, 11 Feb 2017 15:30:46 +0100, Michael Osipov 
wrote:


Am 2017-02-11 um 15:18 schrieb Robert Scholte:

In both cases I'm missing a list of what's being updated (and maybe
why...).
I know there were a couple of plugins for which the latest is not the
greatest due to some small regressions.
So without these details I'd say no.


I am preparing two branches based on Christian's work, so you'll see
what will end up in the merge. No secrets here.

On Sat, 11 Feb 2017 12:06:34 +0100, Michael Osipov  


wrote:


Am 2017-02-08 um 21:14 schrieb Michael Osipov:

Am 2017-02-08 um 21:01 schrieb Stephen Connolly:

I think all the important stuff is merged. I'll take a final review
through
and then cut alpha-1

We can still add stuff if necessary for an alpha-2 but I'd much
prefer to
focus that on shaking out bugs.

Ideally we do at most 3 alpha's before soft-code-freeze and a beta
(at
which point it should only be serious bug fixes)

Then we give the beta some soak and cut the release

I toyed with spinning RCs but I'm thinking alpha and beta are  
better

terms


Looks good to me. I think that the very first alpha should also
include
MNG-5967 Dependency updates
MNG-5968 Default plugin version updates
as well as this cheap, non-functional improvement:
MNG-5934 String handling issues identified by PMD

If Christian is busy, I can take on them.


Christian,

do you mind to merge them into master? If you won't can I take over?

Anyone else seconding those issues?

Michael

-
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





-
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





-
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

Re: I think we are ready for 3.5.0-alpha-1


Am 2017-02-11 um 15:33 schrieb Robert Scholte:

The list of updates should be added to the release notes, I'd say use
the matching JIRA issue.


Do you want me to add these to the issue description itself? Unless I 
create a JIRA issue per dependency, they won't show up in the release 
notes. One could do this with sub-tasks.



branch of MNG-5967 looks good to me.


Thanks, I will merge when all tests pass.

I have now added a MNG-5968 branch, but I think this needs to be broken 
up into three separate issues:


1. Lifecycle/binding plugin version updates
2. Super POM plugin version updates
3. Default plugin version updates

WDYT?


On Sat, 11 Feb 2017 15:30:46 +0100, Michael Osipov 
wrote:


Am 2017-02-11 um 15:18 schrieb Robert Scholte:

In both cases I'm missing a list of what's being updated (and maybe
why...).
I know there were a couple of plugins for which the latest is not the
greatest due to some small regressions.
So without these details I'd say no.


I am preparing two branches based on Christian's work, so you'll see
what will end up in the merge. No secrets here.


On Sat, 11 Feb 2017 12:06:34 +0100, Michael Osipov 
wrote:


Am 2017-02-08 um 21:14 schrieb Michael Osipov:

Am 2017-02-08 um 21:01 schrieb Stephen Connolly:

I think all the important stuff is merged. I'll take a final review
through
and then cut alpha-1

We can still add stuff if necessary for an alpha-2 but I'd much
prefer to
focus that on shaking out bugs.

Ideally we do at most 3 alpha's before soft-code-freeze and a beta
(at
which point it should only be serious bug fixes)

Then we give the beta some soak and cut the release

I toyed with spinning RCs but I'm thinking alpha and beta are better
terms


Looks good to me. I think that the very first alpha should also
include
MNG-5967 Dependency updates
MNG-5968 Default plugin version updates
as well as this cheap, non-functional improvement:
MNG-5934 String handling issues identified by PMD

If Christian is busy, I can take on them.


Christian,

do you mind to merge them into master? If you won't can I take over?

Anyone else seconding those issues?

Michael

-
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





-
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





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

Re: I think we are ready for 3.5.0-alpha-1


Am 2017-02-11 um 13:56 schrieb Stephen Connolly:

MNG-5934 go for it

how will thenother two affect the goal of being a drop in for 3.3.9 (if the
pom I am building assumes version X is default and we are now version Y) or
are these just updates to the Maven core classpath?


Please see the branches for MNG-5967 and MNG-5968 and decide for yourself.


On Sat 11 Feb 2017 at 11:06, Michael Osipov  wrote:


Am 2017-02-08 um 21:14 schrieb Michael Osipov:

Am 2017-02-08 um 21:01 schrieb Stephen Connolly:

I think all the important stuff is merged. I'll take a final review
through
and then cut alpha-1

We can still add stuff if necessary for an alpha-2 but I'd much prefer

to

focus that on shaking out bugs.

Ideally we do at most 3 alpha's before soft-code-freeze and a beta (at
which point it should only be serious bug fixes)

Then we give the beta some soak and cut the release

I toyed with spinning RCs but I'm thinking alpha and beta are better
terms


Looks good to me. I think that the very first alpha should also include
MNG-5967 Dependency updates
MNG-5968 Default plugin version updates
as well as this cheap, non-functional improvement:
MNG-5934 String handling issues identified by PMD

If Christian is busy, I can take on them.


Christian,

do you mind to merge them into master? If you won't can I take over?

Anyone else seconding those issues?

Michael

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

--

Sent from my phone




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

Re: I think we are ready for 3.5.0-alpha-1

2017-02-11 Thread Robert Scholte

The list of updates should be added to the release notes, I'd say use the  
matching JIRA issue.

branch of MNG-5967 looks good to me.

On Sat, 11 Feb 2017 15:30:46 +0100, Michael Osipov   
wrote:



Am 2017-02-11 um 15:18 schrieb Robert Scholte:

In both cases I'm missing a list of what's being updated (and maybe
why...).
I know there were a couple of plugins for which the latest is not the
greatest due to some small regressions.
So without these details I'd say no.


I am preparing two branches based on Christian's work, so you'll see  
what will end up in the merge. No secrets here.



On Sat, 11 Feb 2017 12:06:34 +0100, Michael Osipov 
wrote:


Am 2017-02-08 um 21:14 schrieb Michael Osipov:

Am 2017-02-08 um 21:01 schrieb Stephen Connolly:

I think all the important stuff is merged. I'll take a final review
through
and then cut alpha-1

We can still add stuff if necessary for an alpha-2 but I'd much
prefer to
focus that on shaking out bugs.

Ideally we do at most 3 alpha's before soft-code-freeze and a beta  
(at

which point it should only be serious bug fixes)

Then we give the beta some soak and cut the release

I toyed with spinning RCs but I'm thinking alpha and beta are better
terms


Looks good to me. I think that the very first alpha should also  
include

MNG-5967 Dependency updates
MNG-5968 Default plugin version updates
as well as this cheap, non-functional improvement:
MNG-5934 String handling issues identified by PMD

If Christian is busy, I can take on them.


Christian,

do you mind to merge them into master? If you won't can I take over?

Anyone else seconding those issues?

Michael

-
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





-
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

Re: I think we are ready for 3.5.0-alpha-1


Am 2017-02-11 um 15:18 schrieb Robert Scholte:

In both cases I'm missing a list of what's being updated (and maybe
why...).
I know there were a couple of plugins for which the latest is not the
greatest due to some small regressions.
So without these details I'd say no.


I am preparing two branches based on Christian's work, so you'll see 
what will end up in the merge. No secrets here.



On Sat, 11 Feb 2017 12:06:34 +0100, Michael Osipov 
wrote:


Am 2017-02-08 um 21:14 schrieb Michael Osipov:

Am 2017-02-08 um 21:01 schrieb Stephen Connolly:

I think all the important stuff is merged. I'll take a final review
through
and then cut alpha-1

We can still add stuff if necessary for an alpha-2 but I'd much
prefer to
focus that on shaking out bugs.

Ideally we do at most 3 alpha's before soft-code-freeze and a beta (at
which point it should only be serious bug fixes)

Then we give the beta some soak and cut the release

I toyed with spinning RCs but I'm thinking alpha and beta are better
terms


Looks good to me. I think that the very first alpha should also include
MNG-5967 Dependency updates
MNG-5968 Default plugin version updates
as well as this cheap, non-functional improvement:
MNG-5934 String handling issues identified by PMD

If Christian is busy, I can take on them.


Christian,

do you mind to merge them into master? If you won't can I take over?

Anyone else seconding those issues?

Michael

-
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





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

Re: I think we are ready for 3.5.0-alpha-1

2017-02-11 Thread Robert Scholte

In both cases I'm missing a list of what's being updated (and maybe  
why...).
I know there were a couple of plugins for which the latest is not the  
greatest due to some small regressions.

So without these details I'd say no.

Robert

On Sat, 11 Feb 2017 12:06:34 +0100, Michael Osipov   
wrote:



Am 2017-02-08 um 21:14 schrieb Michael Osipov:

Am 2017-02-08 um 21:01 schrieb Stephen Connolly:

I think all the important stuff is merged. I'll take a final review
through
and then cut alpha-1

We can still add stuff if necessary for an alpha-2 but I'd much prefer  
to

focus that on shaking out bugs.

Ideally we do at most 3 alpha's before soft-code-freeze and a beta (at
which point it should only be serious bug fixes)

Then we give the beta some soak and cut the release

I toyed with spinning RCs but I'm thinking alpha and beta are better
terms


Looks good to me. I think that the very first alpha should also include
MNG-5967 Dependency updates
MNG-5968 Default plugin version updates
as well as this cheap, non-functional improvement:
MNG-5934 String handling issues identified by PMD

If Christian is busy, I can take on them.


Christian,

do you mind to merge them into master? If you won't can I take over?

Anyone else seconding those issues?

Michael

-
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

Re: I think we are ready for 3.5.0-alpha-1

2017-02-11 Thread Stephen Connolly

MNG-5934 go for it

how will thenother two affect the goal of being a drop in for 3.3.9 (if the
pom I am building assumes version X is default and we are now version Y) or
are these just updates to the Maven core classpath?

On Sat 11 Feb 2017 at 11:06, Michael Osipov  wrote:

> Am 2017-02-08 um 21:14 schrieb Michael Osipov:
> > Am 2017-02-08 um 21:01 schrieb Stephen Connolly:
> >> I think all the important stuff is merged. I'll take a final review
> >> through
> >> and then cut alpha-1
> >>
> >> We can still add stuff if necessary for an alpha-2 but I'd much prefer
> to
> >> focus that on shaking out bugs.
> >>
> >> Ideally we do at most 3 alpha's before soft-code-freeze and a beta (at
> >> which point it should only be serious bug fixes)
> >>
> >> Then we give the beta some soak and cut the release
> >>
> >> I toyed with spinning RCs but I'm thinking alpha and beta are better
> >> terms
> >
> > Looks good to me. I think that the very first alpha should also include
> > MNG-5967 Dependency updates
> > MNG-5968 Default plugin version updates
> > as well as this cheap, non-functional improvement:
> > MNG-5934 String handling issues identified by PMD
> >
> > If Christian is busy, I can take on them.
>
> Christian,
>
> do you mind to merge them into master? If you won't can I take over?
>
> Anyone else seconding those issues?
>
> Michael
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

Re: I think we are ready for 3.5.0-alpha-1


Am 2017-02-08 um 21:14 schrieb Michael Osipov:

Am 2017-02-08 um 21:01 schrieb Stephen Connolly:

I think all the important stuff is merged. I'll take a final review
through
and then cut alpha-1

We can still add stuff if necessary for an alpha-2 but I'd much prefer to
focus that on shaking out bugs.

Ideally we do at most 3 alpha's before soft-code-freeze and a beta (at
which point it should only be serious bug fixes)

Then we give the beta some soak and cut the release

I toyed with spinning RCs but I'm thinking alpha and beta are better
terms


Looks good to me. I think that the very first alpha should also include
MNG-5967 Dependency updates
MNG-5968 Default plugin version updates
as well as this cheap, non-functional improvement:
MNG-5934 String handling issues identified by PMD

If Christian is busy, I can take on them.


Christian,

do you mind to merge them into master? If you won't can I take over?

Anyone else seconding those issues?

Michael

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

Re: I think we are ready for 3.5.0-alpha-1

2017-02-10 Thread Robert Scholte

I agree, not for 3.5.0.

Robert

On Fri, 10 Feb 2017 21:07:15 +0100, Stephen Connolly  
 wrote:

These would change dependency resolution and prevent being a drop in for
3.3.9 so unless I hear a good counter-argument, I say no to that branch.
Fine for 3.5.1

On Fri 10 Feb 2017 at 17:55, Christian Schulte  wrote:

Am 02/08/17 um 21:01 schrieb Stephen Connolly:
> I think all the important stuff is merged. I'll take a final review
through
> and then cut alpha-1
>
> We can still add stuff if necessary for an alpha-2 but I'd much  
prefer to

> focus that on shaking out bugs.
>
> Ideally we do at most 3 alpha's before soft-code-freeze and a beta (at
> which point it should only be serious bug fixes)
>
> Then we give the beta some soak and cut the release
>
> I toyed with spinning RCs but I'm thinking alpha and beta are better
terms
>
> Thoughts?
>

Can we add the following issues to 3.5.0 as well? Branch name is
DEPMGMT-IMPORT. In the core repository and the IT repository. No changes
to existing ITs. Just additions.

Issue description says it all. Just adds missing features.

[MNG-4463] Dependency management import should support version ranges.
[MNG-5527] Dependency management import should support relocations.
[MNG-5600] Dependency management import should support exclusions.

We already agreed to this being part of 3.4.0. Shipping this with 3.5.0
instead of 3.5.1 makes sense as the issues qualify for a minor version
increment rather than a bugfix release.

Regards,
--
Christian

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

--

Sent from my phone

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

Re: I think we are ready for 3.5.0-alpha-1

2017-02-10 Thread Stephen Connolly

These would change dependency resolution and prevent being a drop in for
3.3.9 so unless I hear a good counter-argument, I say no to that branch.
Fine for 3.5.1

On Fri 10 Feb 2017 at 17:55, Christian Schulte  wrote:

> Am 02/08/17 um 21:01 schrieb Stephen Connolly:
> > I think all the important stuff is merged. I'll take a final review
> through
> > and then cut alpha-1
> >
> > We can still add stuff if necessary for an alpha-2 but I'd much prefer to
> > focus that on shaking out bugs.
> >
> > Ideally we do at most 3 alpha's before soft-code-freeze and a beta (at
> > which point it should only be serious bug fixes)
> >
> > Then we give the beta some soak and cut the release
> >
> > I toyed with spinning RCs but I'm thinking alpha and beta are better
> terms
> >
> > Thoughts?
> >
>
> Can we add the following issues to 3.5.0 as well? Branch name is
> DEPMGMT-IMPORT. In the core repository and the IT repository. No changes
> to existing ITs. Just additions.
>
> Issue description says it all. Just adds missing features.
>
> [MNG-4463] Dependency management import should support version ranges.
> [MNG-5527] Dependency management import should support relocations.
> [MNG-5600] Dependency management import should support exclusions.
>
> We already agreed to this being part of 3.4.0. Shipping this with 3.5.0
> instead of 3.5.1 makes sense as the issues qualify for a minor version
> increment rather than a bugfix release.
>
> 
> 
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

Re: I think we are ready for 3.5.0-alpha-1

Am 02/08/17 um 21:01 schrieb Stephen Connolly:
> I think all the important stuff is merged. I'll take a final review through
> and then cut alpha-1
> 
> We can still add stuff if necessary for an alpha-2 but I'd much prefer to
> focus that on shaking out bugs.
> 
> Ideally we do at most 3 alpha's before soft-code-freeze and a beta (at
> which point it should only be serious bug fixes)
> 
> Then we give the beta some soak and cut the release
> 
> I toyed with spinning RCs but I'm thinking alpha and beta are better terms
> 
> Thoughts?
> 

Can we add the following issues to 3.5.0 as well? Branch name is
DEPMGMT-IMPORT. In the core repository and the IT repository. No changes
to existing ITs. Just additions.

Issue description says it all. Just adds missing features.

[MNG-4463] Dependency management import should support version ranges.
[MNG-5527] Dependency management import should support relocations.
[MNG-5600] Dependency management import should support exclusions.

We already agreed to this being part of 3.4.0. Shipping this with 3.5.0
instead of 3.5.1 makes sense as the issues qualify for a minor version
increment rather than a bugfix release.




Regards,
-- 
Christian


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

Re: I think we are ready for 3.5.0-alpha-1

Am 02/10/17 um 18:35 schrieb Stephen Connolly:
> I suspect we can just remove `testBrokenProjectSilentlyProcessedUpToVerify`
> as that test doesn't work at all

Updated commit is here:


Previous discussion is not retained on github that way.


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

Re: I think we are ready for 3.5.0-alpha-1

Am 02/10/17 um 18:34 schrieb Stephen Connolly:
> You still have not answered why the overly complex range
> 
> (,3.3.0),[3.3.0,3.3.9],(3.3.9,3.5.0)
> 
> That says:
> * all versions less than 3.3.0; union with
> * all versions greater than or equal to 3.3.0 and less than or equal to
> 3.3.9; union with
> * all versions greater than 3.3.9 and less than 3.5.0
> 
> Which can be simplified to just
> 
> (,3.5.0)

Indeed. Will change that.


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

Re: I think we are ready for 3.5.0-alpha-1

Am 02/10/17 um 18:35 schrieb Stephen Connolly:
> I suspect we can just remove `testBrokenProjectSilentlyProcessedUpToVerify`
> as that test doesn't work at all

Ok. No need to keep it.


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

Re: I think we are ready for 3.5.0-alpha-1

2017-02-10 Thread Stephen Connolly

I suspect we can just remove `testBrokenProjectSilentlyProcessedUpToVerify`
as that test doesn't work at all

On 10 February 2017 at 17:34, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> You still have not answered why the overly complex range
>
> (,3.3.0),[3.3.0,3.3.9],(3.3.9,3.5.0)
>
> That says:
> * all versions less than 3.3.0; union with
> * all versions greater than or equal to 3.3.0 and less than or equal to
> 3.3.9; union with
> * all versions greater than 3.3.9 and less than 3.5.0
>
> Which can be simplified to just
>
> (,3.5.0)
>
>
> On 10 February 2017 at 17:27, Christian Schulte  wrote:
>
>> Am 02/09/17 um 13:08 schrieb Stephen Connolly:
>> > I have added some comments on the integration tests:
>> > https://github.com/apache/maven-integration-testing/commit/f
>> 9c0d641ae362ff59c76bc7eb670c8214917f0c3
>> >
>>
>> Replied there. Is the discussion retained when rebasing the branch? That
>> will change the commit hash.
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
>

Re: I think we are ready for 3.5.0-alpha-1

2017-02-10 Thread Stephen Connolly

You still have not answered why the overly complex range

(,3.3.0),[3.3.0,3.3.9],(3.3.9,3.5.0)

That says:
* all versions less than 3.3.0; union with
* all versions greater than or equal to 3.3.0 and less than or equal to
3.3.9; union with
* all versions greater than 3.3.9 and less than 3.5.0

Which can be simplified to just

(,3.5.0)


On 10 February 2017 at 17:27, Christian Schulte  wrote:

> Am 02/09/17 um 13:08 schrieb Stephen Connolly:
> > I have added some comments on the integration tests:
> > https://github.com/apache/maven-integration-testing/commit/
> f9c0d641ae362ff59c76bc7eb670c8214917f0c3
> >
>
> Replied there. Is the discussion retained when rebasing the branch? That
> will change the commit hash.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: I think we are ready for 3.5.0-alpha-1