date:20170619

[jira] [Closed] (MSHARED-647) display what reports are added automatically when no reportSet is defined

2017-06-19 Thread JIRA


 [ 
https://issues.apache.org/jira/browse/MSHARED-647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hervé Boutemy closed MSHARED-647.
-
Resolution: Fixed

> display what reports are added automatically when no reportSet is defined
> -
>
> Key: MSHARED-647
> URL: https://issues.apache.org/jira/browse/MSHARED-647
> Project: Maven Shared Components
>  Issue Type: Improvement
>  Components: maven-reporting-exec
>Affects Versions: maven-reporting-exec-1.3
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
> Fix For: maven-reporting-exec-1.4
>
>
> for MSITE-787, adding count and list of reports, with "configured" when 
> resportSet is defined or "detected" when they are automatically detected:
> {noformat}[INFO] configuring report plugin 
> org.apache.maven.plugins:maven-checkstyle-plugin:2.15
> [INFO] 1 report configured for maven-checkstyle-plugin:2.15: checkstyle
> [INFO] configuring report plugin org.apache.maven.plugins:maven-pmd-plugin:3.6
> [INFO] 2 reports detected for maven-pmd-plugin:3.6: cpd, pmd
> [INFO] configuring report plugin org.apache.maven.plugins:maven-jxr-plugin:2.5
> [INFO] 2 reports configured for maven-jxr-plugin:2.5: jxr, test-jxr
> [INFO] configuring report plugin org.codehaus.mojo:taglist-maven-plugin:2.4
> [INFO] 1 report detected for taglist-maven-plugin:2.4: taglist{noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (MSITE-787) display what reports are added automatically when no reportSet is defined

2017-06-19 Thread JIRA


 [ 
https://issues.apache.org/jira/browse/MSITE-787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hervé Boutemy closed MSITE-787.
---
Resolution: Fixed
  Assignee: Hervé Boutemy

> display what reports are added automatically when no reportSet is defined
> -
>
> Key: MSITE-787
> URL: https://issues.apache.org/jira/browse/MSITE-787
> Project: Maven Site Plugin
>  Issue Type: Improvement
>Affects Versions: 3.6
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
> Fix For: 3.7
>
>
> when no reportSet is defined, every report is added automatically: this is 
> somewhat magic for most people
> Adding an INFO message would help making things explicit, without cluttering 
> output
> Current output:
> {noformat}[INFO] --- maven-site-plugin:3.5.1:site (default-site) @ 
> maven-site-plugin ---
> [INFO] configuring report plugin 
> org.apache.maven.plugins:maven-project-info-reports-plugin:2.9
> [INFO] configuring report plugin 
> org.apache.maven.plugins:maven-plugin-plugin:3.4
> [INFO] preparing 'report' report requires 'process-classes' forked phase 
> execution{noformat}
> adding another INFO after "configuring report plugin ..." would be natural



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SUREFIRE-1386) Surefire 2.20 breaks tests under linux due to fork problem

2017-06-19 Thread Digant Kumar (JIRA)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-1386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16054944#comment-16054944
 ] 

Digant Kumar commented on SUREFIRE-1386:


Hi [~tibor17],

It is possible that "Surefire is not waiting long enough for the forked VM and 
assumes it to be dead", as mentioned in SUREFIRE-1302.
Lately I have also seen that coverage got dropped by ~5% (we run tests in 
parallel, 12 jvms). This kind of behavior can also be explained with issue like 
SUREFIRE-1302.

I do not have the dump right now, as build was re-triggered and rerun has 
replaced the work-space. Will provide the dump when ever I see such issue again 
next time.


> Surefire 2.20 breaks tests under linux due to fork problem
> --
>
> Key: SUREFIRE-1386
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1386
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20
> Environment: Red Hat Enterprise Linux 6.8
>Reporter: Digant Kumar
>Assignee: Tibor Digana
>Priority: Minor
>
> 19:18:58 [INFO] Tests run: 11712, Failures: 0, Errors: 0, Skipped: 0
> 19:18:58 [INFO] 
> 19:18:58 [INFO] 
> 
> 19:18:58 [INFO] BUILD FAILURE
> 19:18:58 [INFO] 
> 
> 19:18:58 [INFO] Total time: 06:07 min
> 19:18:58 [INFO] Finished at: 2017-06-19T19:18:58+00:00
> 19:18:59 [INFO] Final Memory: 77M/1008M
> 19:18:59 [INFO] 
> 
> 19:18:59 [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.20:test (default-test) on 
> project xx: There are test failures.
> 19:18:59 [ERROR] 
> 19:18:59 [ERROR] Please refer to target/surefire-reports for the individual 
> test results.
> 19:18:59 [ERROR] Please refer to dump files (if any exist) 
> [date]-jvmRun[N].dump, [date].dumpstream and [date]-jvmRun[N].dumpstream.
> 19:18:59 [ERROR] ExecutionException Error occurred in starting fork, check 
> output in log
> 19:18:59 [ERROR] 
> org.apache.maven.surefire.booter.SurefireBooterForkException: 
> ExecutionException Error occurred in starting fork, check output in log
> 19:18:59 [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.awaitResultsDone(ForkStarter.java:494)
> 19:18:59 [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkOnceMultiple(ForkStarter.java:369)
> 19:18:59 [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:292)
> 19:18:59 [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:243)
> 19:18:59 [ERROR] at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1077)
> 19:18:59 [ERROR] at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:907)
> 19:18:59 [ERROR] at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:785)
> 19:18:59 [ERROR] at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> 19:18:59 [ERROR] at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> 19:18:59 [ERROR] at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> 19:18:59 [ERROR] at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> 19:18:59 [ERROR] at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> 19:18:59 [ERROR] at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> 19:18:59 [ERROR] at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> 19:18:59 [ERROR] at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> 19:18:59 [ERROR] at 
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> 19:18:59 [ERROR] at 
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> 19:18:59 [ERROR] at 
> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> 19:18:59 [ERROR] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:862)
> 19:18:59 [ERROR] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:286)
> 19:18:59 [ERROR] at org.apache.maven.cli.MavenCli.main(MavenCli.java:197)
> 19:18:59 [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
> 19:18:59 [ERROR] at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 19:18:59 [ERROR] at 
>

[jira] [Commented] (SUREFIRE-1386) Surefire 2.20 breaks tests under linux due to fork problem

2017-06-19 Thread Tibor Digana (JIRA)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-1386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16054835#comment-16054835
 ] 

Tibor Digana commented on SUREFIRE-1386:


[~digant]
See your logs:
{{19:18:59 [ERROR] Please refer to dump files (if any exist) 
[date]-jvmRun[N].dump, [date].dumpstream and [date]-jvmRun[N].dumpstream.}}
Attach the dump files here in Jira.
I think you have a problem with SUREFIRE-1302 but it can be any of our 
critical/blocker issue where stdout stream in forked jvm is corrupted.

> Surefire 2.20 breaks tests under linux due to fork problem
> --
>
> Key: SUREFIRE-1386
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1386
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20
> Environment: Red Hat Enterprise Linux 6.8
>Reporter: Digant Kumar
>Assignee: Tibor Digana
>Priority: Minor
>
> 19:18:58 [INFO] Tests run: 11712, Failures: 0, Errors: 0, Skipped: 0
> 19:18:58 [INFO] 
> 19:18:58 [INFO] 
> 
> 19:18:58 [INFO] BUILD FAILURE
> 19:18:58 [INFO] 
> 
> 19:18:58 [INFO] Total time: 06:07 min
> 19:18:58 [INFO] Finished at: 2017-06-19T19:18:58+00:00
> 19:18:59 [INFO] Final Memory: 77M/1008M
> 19:18:59 [INFO] 
> 
> 19:18:59 [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.20:test (default-test) on 
> project xx: There are test failures.
> 19:18:59 [ERROR] 
> 19:18:59 [ERROR] Please refer to target/surefire-reports for the individual 
> test results.
> 19:18:59 [ERROR] Please refer to dump files (if any exist) 
> [date]-jvmRun[N].dump, [date].dumpstream and [date]-jvmRun[N].dumpstream.
> 19:18:59 [ERROR] ExecutionException Error occurred in starting fork, check 
> output in log
> 19:18:59 [ERROR] 
> org.apache.maven.surefire.booter.SurefireBooterForkException: 
> ExecutionException Error occurred in starting fork, check output in log
> 19:18:59 [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.awaitResultsDone(ForkStarter.java:494)
> 19:18:59 [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkOnceMultiple(ForkStarter.java:369)
> 19:18:59 [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:292)
> 19:18:59 [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:243)
> 19:18:59 [ERROR] at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1077)
> 19:18:59 [ERROR] at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:907)
> 19:18:59 [ERROR] at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:785)
> 19:18:59 [ERROR] at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> 19:18:59 [ERROR] at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> 19:18:59 [ERROR] at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> 19:18:59 [ERROR] at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> 19:18:59 [ERROR] at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> 19:18:59 [ERROR] at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> 19:18:59 [ERROR] at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> 19:18:59 [ERROR] at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> 19:18:59 [ERROR] at 
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> 19:18:59 [ERROR] at 
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> 19:18:59 [ERROR] at 
> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> 19:18:59 [ERROR] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:862)
> 19:18:59 [ERROR] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:286)
> 19:18:59 [ERROR] at org.apache.maven.cli.MavenCli.main(MavenCli.java:197)
> 19:18:59 [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
> 19:18:59 [ERROR] at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 19:18:59 [ERROR] at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 19:18:59 [ERROR] at

[jira] [Assigned] (SUREFIRE-1386) Surefire 2.20 breaks tests under linux due to fork problem

2017-06-19 Thread Tibor Digana (JIRA)


 [ 
https://issues.apache.org/jira/browse/SUREFIRE-1386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tibor Digana reassigned SUREFIRE-1386:
--

Assignee: Tibor Digana

> Surefire 2.20 breaks tests under linux due to fork problem
> --
>
> Key: SUREFIRE-1386
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1386
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20
> Environment: Red Hat Enterprise Linux 6.8
>Reporter: Digant Kumar
>Assignee: Tibor Digana
>Priority: Minor
>
> 19:18:58 [INFO] Tests run: 11712, Failures: 0, Errors: 0, Skipped: 0
> 19:18:58 [INFO] 
> 19:18:58 [INFO] 
> 
> 19:18:58 [INFO] BUILD FAILURE
> 19:18:58 [INFO] 
> 
> 19:18:58 [INFO] Total time: 06:07 min
> 19:18:58 [INFO] Finished at: 2017-06-19T19:18:58+00:00
> 19:18:59 [INFO] Final Memory: 77M/1008M
> 19:18:59 [INFO] 
> 
> 19:18:59 [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.20:test (default-test) on 
> project xx: There are test failures.
> 19:18:59 [ERROR] 
> 19:18:59 [ERROR] Please refer to target/surefire-reports for the individual 
> test results.
> 19:18:59 [ERROR] Please refer to dump files (if any exist) 
> [date]-jvmRun[N].dump, [date].dumpstream and [date]-jvmRun[N].dumpstream.
> 19:18:59 [ERROR] ExecutionException Error occurred in starting fork, check 
> output in log
> 19:18:59 [ERROR] 
> org.apache.maven.surefire.booter.SurefireBooterForkException: 
> ExecutionException Error occurred in starting fork, check output in log
> 19:18:59 [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.awaitResultsDone(ForkStarter.java:494)
> 19:18:59 [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkOnceMultiple(ForkStarter.java:369)
> 19:18:59 [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:292)
> 19:18:59 [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:243)
> 19:18:59 [ERROR] at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1077)
> 19:18:59 [ERROR] at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:907)
> 19:18:59 [ERROR] at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:785)
> 19:18:59 [ERROR] at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> 19:18:59 [ERROR] at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> 19:18:59 [ERROR] at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> 19:18:59 [ERROR] at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> 19:18:59 [ERROR] at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> 19:18:59 [ERROR] at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> 19:18:59 [ERROR] at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> 19:18:59 [ERROR] at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> 19:18:59 [ERROR] at 
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> 19:18:59 [ERROR] at 
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> 19:18:59 [ERROR] at 
> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> 19:18:59 [ERROR] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:862)
> 19:18:59 [ERROR] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:286)
> 19:18:59 [ERROR] at org.apache.maven.cli.MavenCli.main(MavenCli.java:197)
> 19:18:59 [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
> 19:18:59 [ERROR] at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 19:18:59 [ERROR] at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 19:18:59 [ERROR] at java.lang.reflect.Method.invoke(Method.java:498)
> 19:18:59 [ERROR] at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> 19:18:59 [ERROR] at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> 19:18:59 [ERROR] at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> 19:18:59 [ERROR]

[jira] [Commented] (SUREFIRE-1385) System properties defined in the Surefire and Failsafe plugin configuration should override user properties

2017-06-19 Thread Tibor Digana (JIRA)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16054828#comment-16054828
 ] 

Tibor Digana commented on SUREFIRE-1385:


[~gboue]
I have assigned this issue to version 3.0.

> System properties defined in the Surefire and Failsafe plugin configuration 
> should override user properties
> ---
>
> Key: SUREFIRE-1385
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1385
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: Guillaume Boué
> Fix For: 3.0
>
>
> Consider a build with the following POM configuration for the Maven Failsafe 
> Plugin:
> {code:xml}
> 
>   
> foo
>   
> 
> {code}
> When running the build with the command line {{mvn -Dprop=bar ...}}, the 
> tests would be passed a system property with a value of {{bar}} instead of 
> {{foo}}.
> This is counter-intuitive since direct configuration of the plugin is 
> overriden by the more general properties passed on the command line. I would 
> have expected the closer definition in the POM to override the one passed 
> with the CLI. Furthermore, in the case of the above sample, it would not be 
> possible for the tests run by the Failsafe Plugin to have a system property 
> {{prop}} with a value of {{foo}} if the build happens to already define a 
> system property with the same name. While using a different name to avoid a 
> clash is possible, it still doesn't make the test self-contained and 
> consistent since anyone could run Maven with that other name and compromise 
> the test that really relies on the system property having a value of {{foo}}.
> The proposal is thus to make the {{systemPropertyVariables}} and 
> {{systemPropertiesFile}} configuration elements of the Surefire and Failsafe 
> Plugin take precedence over user properties passed on the command line.
> Proposed commit 
> [4de017b38b101b0b28f9fbed135eae3921b99d0d|http://git-wip-us.apache.org/repos/asf/maven-surefire/commit/4de017b3]
>  on SUREFIRE-1385 branch.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (SUREFIRE-1385) System properties defined in the Surefire and Failsafe plugin configuration should override user properties

2017-06-19 Thread Tibor Digana (JIRA)


 [ 
https://issues.apache.org/jira/browse/SUREFIRE-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tibor Digana updated SUREFIRE-1385:
---
Fix Version/s: 3.0

> System properties defined in the Surefire and Failsafe plugin configuration 
> should override user properties
> ---
>
> Key: SUREFIRE-1385
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1385
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: Guillaume Boué
> Fix For: 3.0
>
>
> Consider a build with the following POM configuration for the Maven Failsafe 
> Plugin:
> {code:xml}
> 
>   
> foo
>   
> 
> {code}
> When running the build with the command line {{mvn -Dprop=bar ...}}, the 
> tests would be passed a system property with a value of {{bar}} instead of 
> {{foo}}.
> This is counter-intuitive since direct configuration of the plugin is 
> overriden by the more general properties passed on the command line. I would 
> have expected the closer definition in the POM to override the one passed 
> with the CLI. Furthermore, in the case of the above sample, it would not be 
> possible for the tests run by the Failsafe Plugin to have a system property 
> {{prop}} with a value of {{foo}} if the build happens to already define a 
> system property with the same name. While using a different name to avoid a 
> clash is possible, it still doesn't make the test self-contained and 
> consistent since anyone could run Maven with that other name and compromise 
> the test that really relies on the system property having a value of {{foo}}.
> The proposal is thus to make the {{systemPropertyVariables}} and 
> {{systemPropertiesFile}} configuration elements of the Surefire and Failsafe 
> Plugin take precedence over user properties passed on the command line.
> Proposed commit 
> [4de017b38b101b0b28f9fbed135eae3921b99d0d|http://git-wip-us.apache.org/repos/asf/maven-surefire/commit/4de017b3]
>  on SUREFIRE-1385 branch.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SUREFIRE-1295) JVM crashes in forks do not log the name of the failing test

2017-06-19 Thread Tibor Digana (JIRA)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16054805#comment-16054805
 ] 

Tibor Digana commented on SUREFIRE-1295:


[~dyaitskov]
I think you have a problem with SUREFIRE-1302. This issue fixed printing tests 
which have not been yet completed.

> JVM crashes in forks do not log the name of the failing test
> 
>
> Key: SUREFIRE-1295
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1295
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Michael Tandy
>Assignee: Tibor Digana
> Fix For: 2.20
>
>
> I am using Surefire to test code accessed through JNI. Sometimes this code 
> will fail, crashing the JVM.
> We run these tests in parallel ( forkCount=1C and reuseForks=false ) and it's 
> not always obvious from the logs, which test caused a JVM crash - and 
> although a command line is printed out, the booter temp files are removed 
> automatically.
> For example:
> {code}
> [INFO] --- maven-surefire-plugin:2.19.1:test (default-test) @ 
> crash-during-test ---
> ---
>  T E S T S
> ---
> Running junit44.environment.BasicTest
> Results :
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 1.337 s
> [INFO] Finished at: 2016-10-26T21:56:45+01:00
> [INFO] Final Memory: 19M/451M
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on 
> project crash-during-test: Execution default-test of goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test failed: The forked 
> VM terminated without properly saying goodbye. VM crash or System.exit called?
> [ERROR] Command was /bin/sh -c cd 
> /home/mtandy/Documents/surefire-vmcrash/maven-surefire/surefire-integration-tests/src/test/resources/crash-during-test
>  && /usr/lib/jvm/java-8-oracle/jre/bin/java -jar 
> /home/mtandy/Documents/surefire-vmcrash/maven-surefire/surefire-integration-tests/src/test/resources/crash-during-test/target/surefire/surefirebooter5241184363018251498.jar
>  
> /home/mtandy/Documents/surefire-vmcrash/maven-surefire/surefire-integration-tests/src/test/resources/crash-during-test/target/surefire/surefire8973747106178765373tmp
>  
> /home/mtandy/Documents/surefire-vmcrash/maven-surefire/surefire-integration-tests/src/test/resources/crash-during-test/target/surefire/surefire_01102526888161398167tmp
> [ERROR] -> [Help 1]
> [ERROR] 
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR] 
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
> {code}
> The situation could be improved if such crashes more closely resembled other 
> test errors - such as by logging the test that was in progress when the crash 
> happened.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SUREFIRE-1376) "The forked VM terminated without properly saying goodbye" when running Surefire in a very deep project structure on Windows

2017-06-19 Thread Tibor Digana (JIRA)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-1376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16054750#comment-16054750
 ] 

Tibor Digana commented on SUREFIRE-1376:


[~gboue]
Did you find bug report for this JDK issue?
I would rather create a new issue for this workaround and we should lookup this 
bug in Oracle. It would be better to have proof from Oracle. We should create 
an IT but I need a help.

> "The forked VM terminated without properly saying goodbye" when running 
> Surefire in a very deep project structure on Windows
> 
>
> Key: SUREFIRE-1376
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1376
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.20
> Environment: Windows
>Reporter: Guillaume Boué
>Assignee: Tibor Digana
> Fix For: 2.20.1
>
> Attachments: SUREFIRE-1376-prefix.patch
>
>
> When Surefire is ran on a project under a very long path (exceeding Windows' 
> {{MAX_PATH}}), the invocation fails with
> {noformat}
> org.apache.maven.surefire.booter.SurefireBooterForkException: The forked VM 
> terminated without properly saying goodbye. VM crash or System.exit called?
> {noformat}
> In the generated dumpstream, there is
> {noformat}
> # Created on 2017-05-28T10:17:09.474
> Error: Unable to access jarfile 
> C:\Users\Guillaume\Desktop\surefire-longpath-test-with-windows\surefire-longpath-test-with-windows\surefire-longpath-test-with-windows\surefire-longpath-test-with-windows\surefire-longpath-test-with-windows\surefire-longpath-test-with-windows\target\surefire\surefirebooter2512478076549179739.jar
> {noformat}
> The problem is that the path to the JAR file exceeds the maximum path length 
> of 260 characters, and so it cannot be accessed.
> Prepending the path to the JAR file with {{?}}, [as documented 
> on 
> MSDN|https://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx#maxpath], 
> makes the test run again correctly. I've attached a possible patch with this 
> approach (SUREFIRE-1376-prefix.patch, that also handles UNC pathnames), but 
> perhaps there is a better way to tackle this problem.
> In order to reproduce this, it is possible to create a project under lots of 
> different subdirectories, something like:
> {noformat}
> └───surefire-longpath-test-with-windows
> └───surefire-longpath-test-with-windows
> └───surefire-longpath-test-with-windows
> └───surefire-longpath-test-with-windows
> └───surefire-longpath-test-with-windows
> │   pom.xml
> │
> └───src
> └───test
> └───java
> └───Test.java
> {noformat}
> As a side-note, this issue is behind the current Jenkins failures on 
> [maven-plugins-ITs-m3.1.x-with-maven-plugin-jdk-1.8_windows|https://builds.apache.org/job/maven-plugins-ITs-m3.1.x-with-maven-plugin-jdk-1.8_windows/3702/]
>  when running the ITs on the Assembly Plugin.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SUREFIRE-1386) Surefire 2.20 breaks tests under linux due to fork problem

2017-06-19 Thread Digant Kumar (JIRA)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-1386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16054704#comment-16054704
 ] 

Digant Kumar commented on SUREFIRE-1386:


Issue is intermittent with Surefire 2.20, though I had never seen it with 
Surefire 2.19.1

> Surefire 2.20 breaks tests under linux due to fork problem
> --
>
> Key: SUREFIRE-1386
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1386
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20
> Environment: Red Hat Enterprise Linux 6.8
>Reporter: Digant Kumar
>Priority: Minor
>
> 19:18:58 [INFO] Tests run: 11712, Failures: 0, Errors: 0, Skipped: 0
> 19:18:58 [INFO] 
> 19:18:58 [INFO] 
> 
> 19:18:58 [INFO] BUILD FAILURE
> 19:18:58 [INFO] 
> 
> 19:18:58 [INFO] Total time: 06:07 min
> 19:18:58 [INFO] Finished at: 2017-06-19T19:18:58+00:00
> 19:18:59 [INFO] Final Memory: 77M/1008M
> 19:18:59 [INFO] 
> 
> 19:18:59 [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.20:test (default-test) on 
> project xx: There are test failures.
> 19:18:59 [ERROR] 
> 19:18:59 [ERROR] Please refer to target/surefire-reports for the individual 
> test results.
> 19:18:59 [ERROR] Please refer to dump files (if any exist) 
> [date]-jvmRun[N].dump, [date].dumpstream and [date]-jvmRun[N].dumpstream.
> 19:18:59 [ERROR] ExecutionException Error occurred in starting fork, check 
> output in log
> 19:18:59 [ERROR] 
> org.apache.maven.surefire.booter.SurefireBooterForkException: 
> ExecutionException Error occurred in starting fork, check output in log
> 19:18:59 [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.awaitResultsDone(ForkStarter.java:494)
> 19:18:59 [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkOnceMultiple(ForkStarter.java:369)
> 19:18:59 [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:292)
> 19:18:59 [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:243)
> 19:18:59 [ERROR] at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1077)
> 19:18:59 [ERROR] at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:907)
> 19:18:59 [ERROR] at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:785)
> 19:18:59 [ERROR] at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> 19:18:59 [ERROR] at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> 19:18:59 [ERROR] at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> 19:18:59 [ERROR] at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> 19:18:59 [ERROR] at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> 19:18:59 [ERROR] at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> 19:18:59 [ERROR] at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> 19:18:59 [ERROR] at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> 19:18:59 [ERROR] at 
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> 19:18:59 [ERROR] at 
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> 19:18:59 [ERROR] at 
> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> 19:18:59 [ERROR] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:862)
> 19:18:59 [ERROR] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:286)
> 19:18:59 [ERROR] at org.apache.maven.cli.MavenCli.main(MavenCli.java:197)
> 19:18:59 [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
> 19:18:59 [ERROR] at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 19:18:59 [ERROR] at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 19:18:59 [ERROR] at java.lang.reflect.Method.invoke(Method.java:498)
> 19:18:59 [ERROR] at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> 19:18:59 [ERROR] at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> 19:18:59 [ERROR] at 
>

[jira] [Created] (SUREFIRE-1386) Surefire 2.20 breaks tests under linux due to fork problem

2017-06-19 Thread Digant Kumar (JIRA)

Digant Kumar created SUREFIRE-1386:
--

 Summary: Surefire 2.20 breaks tests under linux due to fork problem
 Key: SUREFIRE-1386
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1386
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Surefire Plugin
Affects Versions: 2.20
 Environment: Red Hat Enterprise Linux 6.8
Reporter: Digant Kumar
Priority: Minor


19:18:58 [INFO] Tests run: 11712, Failures: 0, Errors: 0, Skipped: 0
19:18:58 [INFO] 
19:18:58 [INFO] 

19:18:58 [INFO] BUILD FAILURE
19:18:58 [INFO] 

19:18:58 [INFO] Total time: 06:07 min
19:18:58 [INFO] Finished at: 2017-06-19T19:18:58+00:00
19:18:59 [INFO] Final Memory: 77M/1008M
19:18:59 [INFO] 

19:18:59 [ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-surefire-plugin:2.20:test (default-test) on 
project xx: There are test failures.
19:18:59 [ERROR] 
19:18:59 [ERROR] Please refer to target/surefire-reports for the individual 
test results.
19:18:59 [ERROR] Please refer to dump files (if any exist) 
[date]-jvmRun[N].dump, [date].dumpstream and [date]-jvmRun[N].dumpstream.
19:18:59 [ERROR] ExecutionException Error occurred in starting fork, check 
output in log
19:18:59 [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: 
ExecutionException Error occurred in starting fork, check output in log
19:18:59 [ERROR] at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.awaitResultsDone(ForkStarter.java:494)
19:18:59 [ERROR] at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkOnceMultiple(ForkStarter.java:369)
19:18:59 [ERROR] at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:292)
19:18:59 [ERROR] at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:243)
19:18:59 [ERROR] at 
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1077)
19:18:59 [ERROR] at 
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:907)
19:18:59 [ERROR] at 
org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:785)
19:18:59 [ERROR] at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
19:18:59 [ERROR] at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
19:18:59 [ERROR] at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
19:18:59 [ERROR] at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
19:18:59 [ERROR] at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
19:18:59 [ERROR] at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
19:18:59 [ERROR] at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
19:18:59 [ERROR] at 
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
19:18:59 [ERROR] at 
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
19:18:59 [ERROR] at 
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
19:18:59 [ERROR] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
19:18:59 [ERROR] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:862)
19:18:59 [ERROR] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:286)
19:18:59 [ERROR] at org.apache.maven.cli.MavenCli.main(MavenCli.java:197)
19:18:59 [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
19:18:59 [ERROR] at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
19:18:59 [ERROR] at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
19:18:59 [ERROR] at java.lang.reflect.Method.invoke(Method.java:498)
19:18:59 [ERROR] at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
19:18:59 [ERROR] at 
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
19:18:59 [ERROR] at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
19:18:59 [ERROR] at 
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
19:18:59 [ERROR] Caused by: 
org.apache.maven.surefire.booter.SurefireBooterForkException: Error occurred in 
starting fork, check output in log
19:18:59 [ERROR] at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:634)
19:18:59 [ERROR] at

[jira] [Commented] (SUREFIRE-1376) "The forked VM terminated without properly saying goodbye" when running Surefire in a very deep project structure on Windows

2017-06-19 Thread JIRA


[ 
https://issues.apache.org/jira/browse/SUREFIRE-1376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16054640#comment-16054640
 ] 

Guillaume Boué commented on SUREFIRE-1376:
--

[~tibor17]

I've detected an issue with this fix: it solves the problem on Oracle JDK 
1.8.0_121, but it doesn't on Oracle JDK 1.7.0_80.

Furthermore, I've tested that changing the launching code from {{java -jar 
?<...>.jar}} to {{java -cp <...>.jar main.class}} works with 
both JDK versions, and without the {{?}} prefix. It looks like 
there is a bug with JDK 7 when deriving the main class from the manifest of a 
JAR under a too long path. Passing directly {{-cp}} and the main class avoids 
that, and the rest of Java code handles the long path just fine. I think commit 
59c065f should be reverted, and replaced with this approach in 
{{ForkConfiguration}}:

{code:java}
File jarFile = createJar( classPath, providerThatHasMainMethod );
cli.createArg().setValue( "-cp" );
cli.createArg().setValue( jarFile.getAbsolutePath() );
cli.createArg().setValue( providerThatHasMainMethod );
{code}

> "The forked VM terminated without properly saying goodbye" when running 
> Surefire in a very deep project structure on Windows
> 
>
> Key: SUREFIRE-1376
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1376
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.20
> Environment: Windows
>Reporter: Guillaume Boué
>Assignee: Tibor Digana
> Fix For: 2.20.1
>
> Attachments: SUREFIRE-1376-prefix.patch
>
>
> When Surefire is ran on a project under a very long path (exceeding Windows' 
> {{MAX_PATH}}), the invocation fails with
> {noformat}
> org.apache.maven.surefire.booter.SurefireBooterForkException: The forked VM 
> terminated without properly saying goodbye. VM crash or System.exit called?
> {noformat}
> In the generated dumpstream, there is
> {noformat}
> # Created on 2017-05-28T10:17:09.474
> Error: Unable to access jarfile 
> C:\Users\Guillaume\Desktop\surefire-longpath-test-with-windows\surefire-longpath-test-with-windows\surefire-longpath-test-with-windows\surefire-longpath-test-with-windows\surefire-longpath-test-with-windows\surefire-longpath-test-with-windows\target\surefire\surefirebooter2512478076549179739.jar
> {noformat}
> The problem is that the path to the JAR file exceeds the maximum path length 
> of 260 characters, and so it cannot be accessed.
> Prepending the path to the JAR file with {{?}}, [as documented 
> on 
> MSDN|https://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx#maxpath], 
> makes the test run again correctly. I've attached a possible patch with this 
> approach (SUREFIRE-1376-prefix.patch, that also handles UNC pathnames), but 
> perhaps there is a better way to tackle this problem.
> In order to reproduce this, it is possible to create a project under lots of 
> different subdirectories, something like:
> {noformat}
> └───surefire-longpath-test-with-windows
> └───surefire-longpath-test-with-windows
> └───surefire-longpath-test-with-windows
> └───surefire-longpath-test-with-windows
> └───surefire-longpath-test-with-windows
> │   pom.xml
> │
> └───src
> └───test
> └───java
> └───Test.java
> {noformat}
> As a side-note, this issue is behind the current Jenkins failures on 
> [maven-plugins-ITs-m3.1.x-with-maven-plugin-jdk-1.8_windows|https://builds.apache.org/job/maven-plugins-ITs-m3.1.x-with-maven-plugin-jdk-1.8_windows/3702/]
>  when running the ITs on the Assembly Plugin.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (MNG-6016) Maven incorrectly builds POM when you override Shade transformers in a child

2017-06-19 Thread Robert Scholte (JIRA)


 [ 
https://issues.apache.org/jira/browse/MNG-6016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Scholte closed MNG-6016.
---
Resolution: Not A Problem
  Assignee: Robert Scholte

The issue here is that the configuration-content is just a bunch of xml tags. 
When Maven tries to merge because of inheritence it is a per-element 
comparison; it is not aware of lists or maps.
So what's happening here is that the second transformer of the parent is merged 
with the second of the child.
With Lists you can simply add the magic attribute {{combine.children="append"}} 
to the transformers-element, which means that the transformer-elements won't be 
merged but appended.
Since Maven 3.3.9 it is also possible to specify {{combine.id}}, which is 
useful in case of Maps. Transformers having the same combine.id in parent and 
child will be merged, the rest will be appended.
Also read 
http://blog.sonatype.com/2011/01/maven-how-to-merging-plugin-configuration-in-complex-projects/
 for more details.

> Maven incorrectly builds POM when you override Shade transformers in a child
> 
>
> Key: MNG-6016
> URL: https://issues.apache.org/jira/browse/MNG-6016
> Project: Maven
>  Issue Type: Bug
>  Components: Inheritance and Interpolation, POM
>Affects Versions: 3.3.9
>Reporter: Steven Schlansker
>Assignee: Robert Scholte
>
> Consider the project: 
> https://github.com/stevenschlansker/maven-configure-transformer-bug/
> Simple 2 module project.  Parent defines some Shade plugin configuration, 
> notably a {{ResourceTransformer}} with a {{mainClass}} declaration.
> Child then tries to add a {{PropertiesMergingResourceTransformer}}, but 
> somehow the {{mainClass}} declaration from the parent gets merged into this 
> other transformer, causing a build failure:
> {quote}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-shade-plugin:2.4.3:shade (assemble-app) on 
> project maven-configure-transformer-bug-child: Unable to parse configuration 
> of mojo org.apache.maven.plugins:maven-shade-plugin:2.4.3:shade for parameter 
> mainClass: Cannot find 'mainClass' in class 
> org.springframework.boot.maven.PropertiesMergingResourceTransformer -> [Help 
> 1]
> {quote}
> The effective POM shows that something extremely unintuitive is going on with 
> model merging:
> {code}
>   
> maven-shade-plugin
> 2.4.3
> 
>   
> assemble-app
> package
> 
>   shade
> 
> 
>   
>  implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
>   META-INF/spring.handlers
> 
>  implementation="org.springframework.boot.maven.PropertiesMergingResourceTransformer">
>   META-INF/spring.factories
>   foo
>   true
> 
>  implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
>   META-INF/spring.schemas
> 
>  implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"
>  />
>  implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer"
>  />
>   
> 
>   
> 
> 
>   
> org.springframework.boot
> spring-boot-maven-plugin
> 1.3.3.RELEASE
> compile
>   
> 
> 
>   
>  implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
>   META-INF/spring.handlers
> 
>  implementation="org.springframework.boot.maven.PropertiesMergingResourceTransformer">
>   META-INF/spring.factories
>   foo
>   true
> 
>  implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
>   META-INF/spring.schemas
> 
>  implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"
>  />
>  implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer"
>  />
>   
> 
>   
> {code}
> It is possible to escape this by adding {{combine.self="override"}} to the 
> {{}} node.  But I think the configuration ending up on the 
> wrong transformer is a bug, and the fact that it causes duplicate 
> configuration sections is also extremely confusing.  And somewhere in the 
> shuffle the original {{CollectingManifestResourceTransformer}} is lost 
> entirely.  (Note that it's not even on the plugin path, so referencing it 
> should be an error!)



--
This message was

[jira] [Commented] (MASSEMBLY-859) Upgrade to Plexus IO 3.0.0

2017-06-19 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/MASSEMBLY-859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16053958#comment-16053958
 ] 

Hudson commented on MASSEMBLY-859:
--

UNSTABLE: Integrated in Jenkins build maven-plugins #9009 (See 
[https://builds.apache.org/job/maven-plugins/9009/])
[MASSEMBLY-859] Upgrade to Plexus IO 3.0.0

This closes #117 (michaelo: 
[http://svn.apache.org/viewvc/?view=rev=1799189])
* (edit) maven-assembly-plugin/pom.xml


> Upgrade to Plexus IO 3.0.0
> --
>
> Key: MASSEMBLY-859
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-859
> Project: Maven Assembly Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.0
>Reporter: Stephane Nicoll
>Assignee: Michael Osipov
> Fix For: 3.1.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MASSEMBLY-860) Upgrade to Java 7

2017-06-19 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/MASSEMBLY-860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16053928#comment-16053928
 ] 

ASF GitHub Bot commented on MASSEMBLY-860:
--

Github user asfgit closed the pull request at:

https://github.com/apache/maven-plugins/pull/116


> Upgrade to Java 7
> -
>
> Key: MASSEMBLY-860
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-860
> Project: Maven Assembly Plugin
>  Issue Type: Improvement
>Affects Versions: 3.0.0
>Reporter: Stephane Nicoll
>Assignee: Michael Osipov
> Fix For: 3.1.0
>
>
> Plexus IO 3 and Plexus Archiver 3.5 requires Java 7 so we need to first 
> upgrade the plugin to Java 7



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MASSEMBLY-859) Upgrade to Plexus IO 3.0.0

2017-06-19 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/MASSEMBLY-859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16053927#comment-16053927
 ] 

ASF GitHub Bot commented on MASSEMBLY-859:
--

Github user asfgit closed the pull request at:

https://github.com/apache/maven-plugins/pull/117


> Upgrade to Plexus IO 3.0.0
> --
>
> Key: MASSEMBLY-859
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-859
> Project: Maven Assembly Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.0
>Reporter: Stephane Nicoll
>Assignee: Michael Osipov
> Fix For: 3.1.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MASSEMBLY-860) Upgrade to Java 7

2017-06-19 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/MASSEMBLY-860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16053923#comment-16053923
 ] 

Hudson commented on MASSEMBLY-860:
--

SUCCESS: Integrated in Jenkins build maven-plugins #9008 (See 
[https://builds.apache.org/job/maven-plugins/9008/])
[MASSEMBLY-860] Upgrade to Java 7

This closes #116 (michaelo: 
[http://svn.apache.org/viewvc/?view=rev=1799186])
* (edit) maven-assembly-plugin/pom.xml
* (edit) pom.xml


> Upgrade to Java 7
> -
>
> Key: MASSEMBLY-860
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-860
> Project: Maven Assembly Plugin
>  Issue Type: Improvement
>Affects Versions: 3.0.0
>Reporter: Stephane Nicoll
>Assignee: Michael Osipov
> Fix For: 3.1.0
>
>
> Plexus IO 3 and Plexus Archiver 3.5 requires Java 7 so we need to first 
> upgrade the plugin to Java 7



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (MASSEMBLY-859) Upgrade to Plexus IO 3.0.0

2017-06-19 Thread Michael Osipov (JIRA)


 [ 
https://issues.apache.org/jira/browse/MASSEMBLY-859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov closed MASSEMBLY-859.

Resolution: Fixed

Fixed with [r1799189|http://svn.apache.org/r1799189].

> Upgrade to Plexus IO 3.0.0
> --
>
> Key: MASSEMBLY-859
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-859
> Project: Maven Assembly Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.0
>Reporter: Stephane Nicoll
>Assignee: Michael Osipov
> Fix For: 3.1.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (MASSEMBLY-859) Upgrade to Plexus IO 3.0.0

2017-06-19 Thread Michael Osipov (JIRA)


 [ 
https://issues.apache.org/jira/browse/MASSEMBLY-859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov reassigned MASSEMBLY-859:


Assignee: Michael Osipov

> Upgrade to Plexus IO 3.0.0
> --
>
> Key: MASSEMBLY-859
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-859
> Project: Maven Assembly Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.0
>Reporter: Stephane Nicoll
>Assignee: Michael Osipov
> Fix For: 3.1.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (MASSEMBLY-860) Upgrade to Java 7

2017-06-19 Thread Michael Osipov (JIRA)


 [ 
https://issues.apache.org/jira/browse/MASSEMBLY-860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov closed MASSEMBLY-860.

Resolution: Fixed

Fixed with [r1799186|http://svn.apache.org/r1799186].

> Upgrade to Java 7
> -
>
> Key: MASSEMBLY-860
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-860
> Project: Maven Assembly Plugin
>  Issue Type: Improvement
>Affects Versions: 3.0.0
>Reporter: Stephane Nicoll
>Assignee: Michael Osipov
> Fix For: 3.1.0
>
>
> Plexus IO 3 and Plexus Archiver 3.5 requires Java 7 so we need to first 
> upgrade the plugin to Java 7



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (MASSEMBLY-860) Upgrade to Java 7

2017-06-19 Thread Michael Osipov (JIRA)


 [ 
https://issues.apache.org/jira/browse/MASSEMBLY-860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov reassigned MASSEMBLY-860:


Assignee: Michael Osipov

> Upgrade to Java 7
> -
>
> Key: MASSEMBLY-860
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-860
> Project: Maven Assembly Plugin
>  Issue Type: Improvement
>Affects Versions: 3.0.0
>Reporter: Stephane Nicoll
>Assignee: Michael Osipov
> Fix For: 3.0.1
>
>
> Plexus IO 3 and Plexus Archiver 3.5 requires Java 7 so we need to first 
> upgrade the plugin to Java 7



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SUREFIRE-1295) JVM crashes in forks do not log the name of the failing test

2017-06-19 Thread Daneel Yaitskov (JIRA)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16053763#comment-16053763
 ] 

Daneel Yaitskov commented on SUREFIRE-1295:
---

I have the same issue with 2.20. I down graded to 2.18.1.

> JVM crashes in forks do not log the name of the failing test
> 
>
> Key: SUREFIRE-1295
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1295
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Michael Tandy
>Assignee: Tibor Digana
> Fix For: 2.20
>
>
> I am using Surefire to test code accessed through JNI. Sometimes this code 
> will fail, crashing the JVM.
> We run these tests in parallel ( forkCount=1C and reuseForks=false ) and it's 
> not always obvious from the logs, which test caused a JVM crash - and 
> although a command line is printed out, the booter temp files are removed 
> automatically.
> For example:
> {code}
> [INFO] --- maven-surefire-plugin:2.19.1:test (default-test) @ 
> crash-during-test ---
> ---
>  T E S T S
> ---
> Running junit44.environment.BasicTest
> Results :
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 1.337 s
> [INFO] Finished at: 2016-10-26T21:56:45+01:00
> [INFO] Final Memory: 19M/451M
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on 
> project crash-during-test: Execution default-test of goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test failed: The forked 
> VM terminated without properly saying goodbye. VM crash or System.exit called?
> [ERROR] Command was /bin/sh -c cd 
> /home/mtandy/Documents/surefire-vmcrash/maven-surefire/surefire-integration-tests/src/test/resources/crash-during-test
>  && /usr/lib/jvm/java-8-oracle/jre/bin/java -jar 
> /home/mtandy/Documents/surefire-vmcrash/maven-surefire/surefire-integration-tests/src/test/resources/crash-during-test/target/surefire/surefirebooter5241184363018251498.jar
>  
> /home/mtandy/Documents/surefire-vmcrash/maven-surefire/surefire-integration-tests/src/test/resources/crash-during-test/target/surefire/surefire8973747106178765373tmp
>  
> /home/mtandy/Documents/surefire-vmcrash/maven-surefire/surefire-integration-tests/src/test/resources/crash-during-test/target/surefire/surefire_01102526888161398167tmp
> [ERROR] -> [Help 1]
> [ERROR] 
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR] 
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
> {code}
> The situation could be improved if such crashes more closely resembled other 
> test errors - such as by logging the test that was in progress when the crash 
> happened.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MASSEMBLY-860) Upgrade to Java 7

2017-06-19 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/MASSEMBLY-860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16053691#comment-16053691
 ] 

ASF GitHub Bot commented on MASSEMBLY-860:
--

GitHub user snicoll opened a pull request:

https://github.com/apache/maven-plugins/pull/116

Upgrade to Java 7

See MASSEMBLY-860

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/snicoll/maven-plugins MASSEMBLY-860

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-plugins/pull/116.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #116


commit 549b9d9ef49e0f663cc6b847fa457d47452d1938
Author: Stephane Nicoll 
Date:   2017-06-19T09:19:57Z

[MASSEMBLY-860] Upgrade to Java 7




> Upgrade to Java 7
> -
>
> Key: MASSEMBLY-860
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-860
> Project: Maven Assembly Plugin
>  Issue Type: Improvement
>Affects Versions: 3.0.0
>Reporter: Stephane Nicoll
> Fix For: 3.0.1
>
>
> Plexus IO 3 and Plexus Archiver 3.5 requires Java 7 so we need to first 
> upgrade the plugin to Java 7



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MASSEMBLY-854) Upgrade to Plexus Archiver 3.5

2017-06-19 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/MASSEMBLY-854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16053698#comment-16053698
 ] 

ASF GitHub Bot commented on MASSEMBLY-854:
--

Github user snicoll closed the pull request at:

https://github.com/apache/maven-plugins/pull/115


> Upgrade to Plexus Archiver 3.5
> --
>
> Key: MASSEMBLY-854
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-854
> Project: Maven Assembly Plugin
>  Issue Type: Task
>Affects Versions: 3.0.0
>Reporter: Stephane Nicoll
> Fix For: 3.0.1
>
>
> There is a critical regression fixed (see 
> https://github.com/codehaus-plexus/plexus-archiver/issues/53)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MASSEMBLY-859) Upgrade to Plexus IO 3.0.0

2017-06-19 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/MASSEMBLY-859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16053696#comment-16053696
 ] 

ASF GitHub Bot commented on MASSEMBLY-859:
--

GitHub user snicoll opened a pull request:

https://github.com/apache/maven-plugins/pull/117

Upgrade to Plexus IO 3.0.0

See MASSEMBLY-859

PR #116 should be merged first as plexus io 3.0.0 requires Java 7

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/snicoll/maven-plugins MASSEMBLY-859

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-plugins/pull/117.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #117


commit 32c7570a3e8c1aa99e0ebf8a792136bca729b7f1
Author: Stephane Nicoll 
Date:   2017-06-19T09:23:24Z

[MASSEMBLY-859] Upgrade to Plexus IO 3.0.0




> Upgrade to Plexus IO 3.0.0
> --
>
> Key: MASSEMBLY-859
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-859
> Project: Maven Assembly Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.0
>Reporter: Stephane Nicoll
> Fix For: 3.0.1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MASSEMBLY-860) Upgrade to Java 7

2017-06-19 Thread Stephane Nicoll (JIRA)

Stephane Nicoll created MASSEMBLY-860:
-

 Summary: Upgrade to Java 7
 Key: MASSEMBLY-860
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-860
 Project: Maven Assembly Plugin
  Issue Type: Improvement
Affects Versions: 3.0.0
Reporter: Stephane Nicoll
 Fix For: 3.0.1


Plexus IO 3 and Plexus Archiver 3.5 requires Java 7 so we need to first upgrade 
the plugin to Java 7



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MASSEMBLY-859) Upgrade to Plexus IO 3.0.0

2017-06-19 Thread Stephane Nicoll (JIRA)

Stephane Nicoll created MASSEMBLY-859:
-

 Summary: Upgrade to Plexus IO 3.0.0
 Key: MASSEMBLY-859
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-859
 Project: Maven Assembly Plugin
  Issue Type: Dependency upgrade
Affects Versions: 3.0.0
Reporter: Stephane Nicoll
 Fix For: 3.0.1






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (MNG-6016) Maven incorrectly builds POM when you override Shade transformers in a child

2017-06-19 Thread Frank Wein (JIRA)


[ 
https://issues.apache.org/jira/browse/MNG-6016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16053547#comment-16053547
 ] 

Frank Wein edited comment on MNG-6016 at 6/19/17 7:56 AM:
--

I also observe this problem with a project of myself. Did someone already have 
a chance to test this with Maven 3.5?


was (Author: fwein):
I also observe this problem with a project of myself. Did someone already have 
a change to test this with Maven 3.5?

> Maven incorrectly builds POM when you override Shade transformers in a child
> 
>
> Key: MNG-6016
> URL: https://issues.apache.org/jira/browse/MNG-6016
> Project: Maven
>  Issue Type: Bug
>  Components: Inheritance and Interpolation, POM
>Affects Versions: 3.3.9
>Reporter: Steven Schlansker
>
> Consider the project: 
> https://github.com/stevenschlansker/maven-configure-transformer-bug/
> Simple 2 module project.  Parent defines some Shade plugin configuration, 
> notably a {{ResourceTransformer}} with a {{mainClass}} declaration.
> Child then tries to add a {{PropertiesMergingResourceTransformer}}, but 
> somehow the {{mainClass}} declaration from the parent gets merged into this 
> other transformer, causing a build failure:
> {quote}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-shade-plugin:2.4.3:shade (assemble-app) on 
> project maven-configure-transformer-bug-child: Unable to parse configuration 
> of mojo org.apache.maven.plugins:maven-shade-plugin:2.4.3:shade for parameter 
> mainClass: Cannot find 'mainClass' in class 
> org.springframework.boot.maven.PropertiesMergingResourceTransformer -> [Help 
> 1]
> {quote}
> The effective POM shows that something extremely unintuitive is going on with 
> model merging:
> {code}
>   
> maven-shade-plugin
> 2.4.3
> 
>   
> assemble-app
> package
> 
>   shade
> 
> 
>   
>  implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
>   META-INF/spring.handlers
> 
>  implementation="org.springframework.boot.maven.PropertiesMergingResourceTransformer">
>   META-INF/spring.factories
>   foo
>   true
> 
>  implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
>   META-INF/spring.schemas
> 
>  implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"
>  />
>  implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer"
>  />
>   
> 
>   
> 
> 
>   
> org.springframework.boot
> spring-boot-maven-plugin
> 1.3.3.RELEASE
> compile
>   
> 
> 
>   
>  implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
>   META-INF/spring.handlers
> 
>  implementation="org.springframework.boot.maven.PropertiesMergingResourceTransformer">
>   META-INF/spring.factories
>   foo
>   true
> 
>  implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
>   META-INF/spring.schemas
> 
>  implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"
>  />
>  implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer"
>  />
>   
> 
>   
> {code}
> It is possible to escape this by adding {{combine.self="override"}} to the 
> {{}} node.  But I think the configuration ending up on the 
> wrong transformer is a bug, and the fact that it causes duplicate 
> configuration sections is also extremely confusing.  And somewhere in the 
> shuffle the original {{CollectingManifestResourceTransformer}} is lost 
> entirely.  (Note that it's not even on the plugin path, so referencing it 
> should be an error!)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MNG-6016) Maven incorrectly builds POM when you override Shade transformers in a child

2017-06-19 Thread Frank Wein (JIRA)


[ 
https://issues.apache.org/jira/browse/MNG-6016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16053547#comment-16053547
 ] 

Frank Wein commented on MNG-6016:
-

I also observe this problem with a project of myself. Did someone already have 
a change to test this with Maven 3.5?

> Maven incorrectly builds POM when you override Shade transformers in a child
> 
>
> Key: MNG-6016
> URL: https://issues.apache.org/jira/browse/MNG-6016
> Project: Maven
>  Issue Type: Bug
>  Components: Inheritance and Interpolation, POM
>Affects Versions: 3.3.9
>Reporter: Steven Schlansker
>
> Consider the project: 
> https://github.com/stevenschlansker/maven-configure-transformer-bug/
> Simple 2 module project.  Parent defines some Shade plugin configuration, 
> notably a {{ResourceTransformer}} with a {{mainClass}} declaration.
> Child then tries to add a {{PropertiesMergingResourceTransformer}}, but 
> somehow the {{mainClass}} declaration from the parent gets merged into this 
> other transformer, causing a build failure:
> {quote}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-shade-plugin:2.4.3:shade (assemble-app) on 
> project maven-configure-transformer-bug-child: Unable to parse configuration 
> of mojo org.apache.maven.plugins:maven-shade-plugin:2.4.3:shade for parameter 
> mainClass: Cannot find 'mainClass' in class 
> org.springframework.boot.maven.PropertiesMergingResourceTransformer -> [Help 
> 1]
> {quote}
> The effective POM shows that something extremely unintuitive is going on with 
> model merging:
> {code}
>   
> maven-shade-plugin
> 2.4.3
> 
>   
> assemble-app
> package
> 
>   shade
> 
> 
>   
>  implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
>   META-INF/spring.handlers
> 
>  implementation="org.springframework.boot.maven.PropertiesMergingResourceTransformer">
>   META-INF/spring.factories
>   foo
>   true
> 
>  implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
>   META-INF/spring.schemas
> 
>  implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"
>  />
>  implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer"
>  />
>   
> 
>   
> 
> 
>   
> org.springframework.boot
> spring-boot-maven-plugin
> 1.3.3.RELEASE
> compile
>   
> 
> 
>   
>  implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
>   META-INF/spring.handlers
> 
>  implementation="org.springframework.boot.maven.PropertiesMergingResourceTransformer">
>   META-INF/spring.factories
>   foo
>   true
> 
>  implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
>   META-INF/spring.schemas
> 
>  implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"
>  />
>  implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer"
>  />
>   
> 
>   
> {code}
> It is possible to escape this by adding {{combine.self="override"}} to the 
> {{}} node.  But I think the configuration ending up on the 
> wrong transformer is a bug, and the fact that it causes duplicate 
> configuration sections is also extremely confusing.  And somewhere in the 
> shuffle the original {{CollectingManifestResourceTransformer}} is lost 
> entirely.  (Note that it's not even on the plugin path, so referencing it 
> should be an error!)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (MSHARED-647) display what reports are added automatically when no reportSet is defined

[jira] [Closed] (MSITE-787) display what reports are added automatically when no reportSet is defined

[jira] [Commented] (SUREFIRE-1386) Surefire 2.20 breaks tests under linux due to fork problem

[jira] [Commented] (SUREFIRE-1386) Surefire 2.20 breaks tests under linux due to fork problem

[jira] [Assigned] (SUREFIRE-1386) Surefire 2.20 breaks tests under linux due to fork problem

[jira] [Commented] (SUREFIRE-1385) System properties defined in the Surefire and Failsafe plugin configuration should override user properties

[jira] [Updated] (SUREFIRE-1385) System properties defined in the Surefire and Failsafe plugin configuration should override user properties

[jira] [Commented] (SUREFIRE-1295) JVM crashes in forks do not log the name of the failing test

[jira] [Commented] (SUREFIRE-1376) "The forked VM terminated without properly saying goodbye" when running Surefire in a very deep project structure on Windows

[jira] [Commented] (SUREFIRE-1386) Surefire 2.20 breaks tests under linux due to fork problem

[jira] [Created] (SUREFIRE-1386) Surefire 2.20 breaks tests under linux due to fork problem

[jira] [Commented] (SUREFIRE-1376) "The forked VM terminated without properly saying goodbye" when running Surefire in a very deep project structure on Windows

[jira] [Closed] (MNG-6016) Maven incorrectly builds POM when you override Shade transformers in a child

[jira] [Commented] (MASSEMBLY-859) Upgrade to Plexus IO 3.0.0

[jira] [Commented] (MASSEMBLY-860) Upgrade to Java 7

[jira] [Commented] (MASSEMBLY-859) Upgrade to Plexus IO 3.0.0

[jira] [Commented] (MASSEMBLY-860) Upgrade to Java 7

[jira] [Closed] (MASSEMBLY-859) Upgrade to Plexus IO 3.0.0

[jira] [Assigned] (MASSEMBLY-859) Upgrade to Plexus IO 3.0.0

[jira] [Closed] (MASSEMBLY-860) Upgrade to Java 7

[jira] [Assigned] (MASSEMBLY-860) Upgrade to Java 7

[jira] [Commented] (SUREFIRE-1295) JVM crashes in forks do not log the name of the failing test

[jira] [Commented] (MASSEMBLY-860) Upgrade to Java 7

[jira] [Commented] (MASSEMBLY-854) Upgrade to Plexus Archiver 3.5

[jira] [Commented] (MASSEMBLY-859) Upgrade to Plexus IO 3.0.0

[jira] [Created] (MASSEMBLY-860) Upgrade to Java 7

[jira] [Created] (MASSEMBLY-859) Upgrade to Plexus IO 3.0.0

[jira] [Comment Edited] (MNG-6016) Maven incorrectly builds POM when you override Shade transformers in a child

[jira] [Commented] (MNG-6016) Maven incorrectly builds POM when you override Shade transformers in a child

29 matches

Site Navigation

Mail list logo

Footer information