Re: Build Maven offline

[Christian Schulte]

Am 02/13/17 um 17:47 schrieb Guo Yunhe:
>> Don't. Don't do the same as done here: 
>> https://www.rpmfind.net/linux/RPM/fedora/25/s390x/m/maven-3.3.9-6.fc25.noarch.html
>>
>> The completely disassembled your tarball and build Maven theirselves. This 
>> is a non-canoncial build which we are likely not going to support! The 
>> modifications to this aren't known to us. Rather untar our offical tarball 
>> and rebuilt your package.
>>
>> Though, you have to grab the tarball from the Internet somehow.
>>
>> Michael
> 
> I know what you worry about. But the packaging system doesn't allow internet 
> download and compiled binary usually. I have to build it from source somehow.

It does not need to download the sources from somewhere? Others just
fetch the binary distribution and build a package from that. No need to
compile anything [1]. Only things you could patch are the configuration
files (like the global default settings.xml) that way. If you really
need to modify Maven sources, it's better to  present the modifications
here so that we can find a solution we can ship in the binary distribution.

[1] 

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

[Tibor Digana]

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 

[GitHub] maven-surefire issue #142: SUREFIRE-1330: Import provider code donated by JU...

[Tibor17]

Github user Tibor17 commented on the issue:

https://github.com/apache/maven-surefire/pull/142
  
@britter 
@marcphilipp 
Done. We are preparing a new release version of Maven and Surefire was 
examined last days. We still investigate some issues.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] maven-surefire pull request #142: SUREFIRE-1330: Import provider code donate...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/maven-surefire/pull/142


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

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

[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

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

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: Possible bug in Maven-core

[Robert Scholte]

Hi Peter,

I would consider this as a Maven Archetype issue.
Regarding the properties, the MavenSession has a deprecated method  
getExecutionProperties(), which is split up into getSystemProperties() and  
getUserProperties(). When using the Invoker it doesn't make sense to add  
SystemProperties (again), userProperties (-Dkey=value entries) should be  
enough. But it could be I missed a usecase, which also implies there are  
not enough integration tests.


AFAIK we're never creating a new ProjectBuildingRequest, we should be  
using the original or a clone of it, so the suggestion to set both types  
of properties seems weird.


If you can create a JIRA issue for ARCHETYPE with a small integration test  
for the plugin, it shouldn't be so hard to fix it.


thanks,
Robert

On Mon, 13 Feb 2017 16:35:18 +0100, Petar Tahchiev   
wrote:



Hi guys,

I'm writing here to ask what I have found is a bug or not. I have a  
project
and I want to create an archetype out of it. So I use the following  
command:


mvn archetype:create-from-project
-Darchetype.properties=src/main/resources/archetype.properties

It used to work fine with maven-archetype<=2.4 but now with 3.0 it fails
with:

Caused by: org.apache.maven.plugin.MojoFailureException: Error reading
parent POM of project: com.nemesis:bom:1.5.0.BUILD-SNAPSHOT
at
org.apache.maven.archetype.mojos.CreateArchetypeFromProjectMojo.execute(CreateArchetypeFromProjectMojo.java:269)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)

I started debugging and I found out that the problem is in this commit:

https://github.com/apache/maven-archetype/commit/624f9affdc27c8efe6443e03e89259dbe51d08dd

which migrates the plugin to Maven3.

Furthermore debugging and stacktrace analysis revealed this:


*[ERROR] Failed to determine Java version for profile  
doclint-java8-disable

@ org.jboss:jboss-parent:19,
/home/petar/.m2/repository/org/jboss/jboss-parent/19/jboss-parent-19.pom,
line 746, column 15*
and indeed inside my parent pom.xml I have included the jboss bom like  
this:



org.drools
drools-bom
pom
${drools.version}
import


which has a parent the jboss-parent.

Now if you debug further more in the maven-archetype-plugin you will see
here:

https://github.com/apache/maven-archetype/blob/master/archetype-common/src/main/java/org/apache/maven/archetype/creator/FilesetArchetypeCreator.java#L439

we create a new DefaultProjectBuildingRequest and don't set any system
properties to it
so it eventually gets passed down to maven-core which cannot find
"java.version"
system property (because there are no properties passed) and it adds the
error that I see.

Now I have a several questions: why have we left the  
ProjectBuildingRequest

without system properties? Also the ProjectBuildingRequest has no
userProperties set - is this OK? I can fix the system properties with:

buildingRequest.setSystemProperties( System.getProperties() );
buildingRequest.setUserProperties( configurationProperties );

but is this correct?



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

Re: Build Maven offline

[Michael Osipov]

Am 2017-02-13 um 17:47 schrieb Guo Yunhe:

Don't. Don't do the same as done here: 
https://www.rpmfind.net/linux/RPM/fedora/25/s390x/m/maven-3.3.9-6.fc25.noarch.html

The completely disassembled your tarball and build Maven theirselves. This is a 
non-canoncial build which we are likely not going to support! The modifications 
to this aren't known to us. Rather untar our offical tarball and rebuilt your 
package.

Though, you have to grab the tarball from the Internet somehow.

Michael


I know what you worry about. But the packaging system doesn't allow internet 
download and compiled binary usually. I have to build it from source somehow.


Then you have two problems:
1. You will require Internet access even if you build from source
2. A non-canonical build will not be supported by us.

Same does Mark Thomas with Apache Tomcat. If people have problems with 
Tomcat with a OS-/distribution-bundled version, he requests a canonical 
version from ASF directly.


Michael


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

Re: Build Maven offline

[Benson Margulies]

Then don't include it in the distro. Packaging non-standard, possibly
broken, versions in distros is not doing anyone any favors. Users are
better off just downloading for themselves.

On Mon, Feb 13, 2017 at 8:47 AM, Guo Yunhe  wrote:
>> Don't. Don't do the same as done here: 
>> https://www.rpmfind.net/linux/RPM/fedora/25/s390x/m/maven-3.3.9-6.fc25.noarch.html
>>
>> The completely disassembled your tarball and build Maven theirselves. This 
>> is a non-canoncial build which we are likely not going to support! The 
>> modifications to this aren't known to us. Rather untar our offical tarball 
>> and rebuilt your package.
>>
>> Though, you have to grab the tarball from the Internet somehow.
>>
>> Michael
>
> I know what you worry about. But the packaging system doesn't allow internet 
> download and compiled binary usually. I have to build it from source somehow.
>
> --
> Guo Yunhe
> Aalto University
> Espoo, Finland
>
> -
> 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: Re: I think we are ready for 3.5.0-alpha-1

[Tibor Digana]

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

[Tibor Digana]

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: Build Maven offline

[Guo Yunhe]

> Don't. Don't do the same as done here: 
> https://www.rpmfind.net/linux/RPM/fedora/25/s390x/m/maven-3.3.9-6.fc25.noarch.html
> 
> The completely disassembled your tarball and build Maven theirselves. This is 
> a non-canoncial build which we are likely not going to support! The 
> modifications to this aren't known to us. Rather untar our offical tarball 
> and rebuilt your package.
> 
> Though, you have to grab the tarball from the Internet somehow.
> 
> Michael

I know what you worry about. But the packaging system doesn't allow internet 
download and compiled binary usually. I have to build it from source somehow.

-- 
Guo Yunhe
Aalto University
Espoo, Finland

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

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

[Tibor Digana]

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: Build Maven offline

[Michael Osipov]

> Hi, I am a contributor of openSUSE Linux. I am packaging maven package.
> 
> Building maven from source requires internet connection and downloads extra 
> packages. However, the openSUSE build server doesn't allow any downloads from 
> internet while building. So I want to ask if I can build maven totally 
> offline, without checking and downloading dependencies from internet?


Don't. Don't do the same as done here: 
https://www.rpmfind.net/linux/RPM/fedora/25/s390x/m/maven-3.3.9-6.fc25.noarch.html

The completely disassembled your tarball and build Maven theirselves. This is a 
non-canoncial build which we are likely not going to support! The modifications 
to this aren't known to us. Rather untar our offical tarball and rebuilt your 
package.

Though, you have to grab the tarball from the Internet somehow.

Michael

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

Build Maven offline

[Guo Yunhe]

Hi, I am a contributor of openSUSE Linux. I am packaging maven package.

Building maven from source requires internet connection and downloads extra 
packages. However, the openSUSE build server doesn't allow any downloads from 
internet while building. So I want to ask if I can build maven totally offline, 
without checking and downloading dependencies from internet?

Thanks!

-- 
Guo Yunhe
Aalto University
Espoo, Finland

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

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

[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

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

Possible bug in Maven-core

[Petar Tahchiev]

Hi guys,

I'm writing here to ask what I have found is a bug or not. I have a project
and I want to create an archetype out of it. So I use the following command:

mvn archetype:create-from-project
-Darchetype.properties=src/main/resources/archetype.properties

It used to work fine with maven-archetype<=2.4 but now with 3.0 it fails
with:

Caused by: org.apache.maven.plugin.MojoFailureException: Error reading
parent POM of project: com.nemesis:bom:1.5.0.BUILD-SNAPSHOT
at
org.apache.maven.archetype.mojos.CreateArchetypeFromProjectMojo.execute(CreateArchetypeFromProjectMojo.java:269)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)

I started debugging and I found out that the problem is in this commit:

https://github.com/apache/maven-archetype/commit/624f9affdc27c8efe6443e03e89259dbe51d08dd

which migrates the plugin to Maven3.

Furthermore debugging and stacktrace analysis revealed this:


*[ERROR] Failed to determine Java version for profile doclint-java8-disable
@ org.jboss:jboss-parent:19,
/home/petar/.m2/repository/org/jboss/jboss-parent/19/jboss-parent-19.pom,
line 746, column 15*
and indeed inside my parent pom.xml I have included the jboss bom like this:


org.drools
drools-bom
pom
${drools.version}
import


which has a parent the jboss-parent.

Now if you debug further more in the maven-archetype-plugin you will see
here:

https://github.com/apache/maven-archetype/blob/master/archetype-common/src/main/java/org/apache/maven/archetype/creator/FilesetArchetypeCreator.java#L439

we create a new DefaultProjectBuildingRequest and don't set any system
properties to it
so it eventually gets passed down to maven-core which cannot find
"java.version"
system property (because there are no properties passed) and it adds the
error that I see.

Now I have a several questions: why have we left the ProjectBuildingRequest
without system properties? Also the ProjectBuildingRequest has no
userProperties set - is this OK? I can fix the system properties with:

buildingRequest.setSystemProperties( System.getProperties() );
buildingRequest.setUserProperties( configurationProperties );

but is this correct?


-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
http://pgp.mit.edu:11371/pks/lookup?op=get=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

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

[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