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

[Christian Schulte]

Am 02/14/17 um 20:25 schrieb Michael Osipov:
> Who seconds MNG-6150 Javadoc improvements for 3.5.0 for FIX-3.5.0? 
> Functional changes, passes all tests.

+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

[Tibor Digana]

We are dumping the std/out because it seems the event "Z,0,BYE!" was
missing.
I need to confirm the stream.
Maybe it will be okay now because I have applied a local patch and sent
three Java files to Michael.
If this does not help, we will dump received events. It's enough to test
with single IT test which is faster.

On Tue, Feb 14, 2017 at 11:25 PM, Michael Osipov-2 [via Maven] <
ml-node+s40175n5898720...@n5.nabble.com> wrote:

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

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

[Michael Osipov]

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

[Robert Scholte]

Hi Peter,

I've committed the fix based on your test. In fact with Maven3 things are  
much simpler.


thanks,
Robert

On Tue, 14 Feb 2017 12:54:31 +0100, Petar Tahchiev   
wrote:



Hi Robert,

this:


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.

is not true:

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

You can clearly see that if the project.getParent() != null a new
DefaultProjectBuildingRequest(); is created and that new request is  
missing

the system properties and the user-specified properties.

As suggested I have opened a ticket here:
https://issues.apache.org/jira/browse/ARCHETYPE-518

Also, again, as suggested I have just committed a test-case inside
DefaultArchetypeCreatorIT#testSystemPropertiesAreIncluded

At the moment that test fails with null-pointer exception because the
archetype is using maven-core version 3.0 for its tests.

I've tested with both - with latest maven 3.5.x-SNAPSHOT - I get a
different kind of error
  - with maven 3.0.4 i get the exact same
null-pointer as the test suggests.


Finally I have also committed 2 lines inside FilesetArchetypeCreator to
resolve the issue:

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

Please let me know if you are OK with this.

Thank you.


2017-02-13 20:54 GMT+02:00 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.CreateArchetypeFromProjectM
ojo.execute(CreateArchetypeFromProjectMojo.java:269)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMoj
o(DefaultBuildPluginManager.java:134)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(Moj
oExecutor.java:207)

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

https://github.com/apache/maven-archetype/commit/624f9affdc2
7c8efe6443e03e89259dbe51d08dd

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/archet
ype-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?

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

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

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

[Michael Osipov]

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,

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

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



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 

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

[Michael Osipov]

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

[Michael Osipov]

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

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

Running a plugin integration test from an IDE?

[org . apache . maven . user]

Hello.

I'm having a look at working on
https://issues.apache.org/jira/browse/MASSEMBLY-848 but I've never
worked on any of the "official" Maven plugins before. It seems like
the most obvious way to start working on the bug is to introduce the
files attached to that report as an integration test in the bugs
subdirectory. However, I can't work out how to run this integration
test from an IDE (Intellij IDEA, in this case) so that I can try to
step through the execution with a debugger and see what's going on.

Could somebody point me in the right direction?

M


pgpGjkvULo0yn.pgp
Description: OpenPGP digital signature

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

[Michael Osipov]

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

[Petar Tahchiev]

Hi Robert,

this:


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.

is not true:

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

You can clearly see that if the project.getParent() != null a new
DefaultProjectBuildingRequest(); is created and that new request is missing
the system properties and the user-specified properties.

As suggested I have opened a ticket here:
https://issues.apache.org/jira/browse/ARCHETYPE-518

Also, again, as suggested I have just committed a test-case inside
DefaultArchetypeCreatorIT#testSystemPropertiesAreIncluded

At the moment that test fails with null-pointer exception because the
archetype is using maven-core version 3.0 for its tests.

I've tested with both - with latest maven 3.5.x-SNAPSHOT - I get a
different kind of error
  - with maven 3.0.4 i get the exact same
null-pointer as the test suggests.


Finally I have also committed 2 lines inside FilesetArchetypeCreator to
resolve the issue:

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

Please let me know if you are OK with this.

Thank you.


2017-02-13 20:54 GMT+02:00 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.CreateArchetypeFromProjectM
>> ojo.execute(CreateArchetypeFromProjectMojo.java:269)
>> at
>> org.apache.maven.plugin.DefaultBuildPluginManager.executeMoj
>> o(DefaultBuildPluginManager.java:134)
>> at
>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(Moj
>> oExecutor.java:207)
>>
>> I started debugging and I found out that the problem is in this commit:
>>
>> https://github.com/apache/maven-archetype/commit/624f9affdc2
>> 7c8efe6443e03e89259dbe51d08dd
>>
>> 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/archet
>> ype-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?
>>
>>
> 

Re: Re: Build Maven offline

[Michael Osipov]

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

Infact, I have added "Introduce ${maven.conf} in m2.conf" in MNG-6102 which
should make that type of conf modification to /etc or /usr/local/etc a snap.

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

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

[britter]

Github user britter commented on the issue:

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


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