[jira] [Commented] (SUREFIRE-1478) VM Crash org.apache.maven.plugins:maven-surefire-plugin:2.12.4

[*$^¨%`£]

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

Olivier Lamy (*$^¨%`£) commented on SUREFIRE-1478:
--

oops my bad the last one is 2.20.1

sorry

> VM Crash org.apache.maven.plugins:maven-surefire-plugin:2.12.4
> --
>
> Key: SUREFIRE-1478
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1478
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: JUnit 5.x support
>Affects Versions: 2.20.1
> Environment: Apache Maven 3.5.2 
> (138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T01:58:13-06:00)
> Maven home: C:\Program Files\apache-maven-3.5.2\bin\..
> Java version: 1.8.0_162, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_162\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Matt Sullivan
>Priority: Major
>  Labels: maven, newbie, windows
>
> Maven crashes with:
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test (default-test)
>  on project big-number
>  : Execution default-test of goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.12.4
>  :test failed: The forked VM terminated without saying properly goodbye. VM 
> crash or System.exit called ? -> [Help 1]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SUREFIRE-1478) VM Crash org.apache.maven.plugins:maven-surefire-plugin:2.12.4

[Matt Sullivan (JIRA)]

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

Matt Sullivan commented on SUREFIRE-1478:
-

Will do.  When will it be available in the repository 
[https://mvnrepository.com/artifact/org.apache.maven.plugins/maven-surefire-plugin]

I currently get: Could not find artifact 
org.apache.maven.plugins:maven-surefire-plugin:jar:2.22.1 in central 
([https://repo.maven.apache.org/maven2)]

 

> VM Crash org.apache.maven.plugins:maven-surefire-plugin:2.12.4
> --
>
> Key: SUREFIRE-1478
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1478
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: JUnit 5.x support
>Affects Versions: 2.20.1
> Environment: Apache Maven 3.5.2 
> (138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T01:58:13-06:00)
> Maven home: C:\Program Files\apache-maven-3.5.2\bin\..
> Java version: 1.8.0_162, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_162\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Matt Sullivan
>Priority: Major
>  Labels: maven, newbie, windows
>
> Maven crashes with:
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test (default-test)
>  on project big-number
>  : Execution default-test of goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.12.4
>  :test failed: The forked VM terminated without saying properly goodbye. VM 
> crash or System.exit called ? -> [Help 1]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MINSTALL-115) Setting installAtEnd causes no installs to occur when a multimodule project has multiple class realms

[Charles Honton (JIRA)]

[ 
https://issues.apache.org/jira/browse/MINSTALL-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16370902#comment-16370902
 ] 

Charles Honton commented on MINSTALL-115:
-

I suspect installAtEnd has same problems as deployAtEnd.  see MDEPLOY-200, 
MDEPLOY-224, MDEPLOY-225, and MDEPLOY-226 for a solution.

> Setting installAtEnd causes no installs to occur when a multimodule project 
> has multiple class realms
> -
>
> Key: MINSTALL-115
> URL: https://issues.apache.org/jira/browse/MINSTALL-115
> Project: Maven Install Plugin
>  Issue Type: Bug
>  Components: install:install
>Affects Versions: 2.5.2
>Reporter: Philip Pearson
>Priority: Major
> Attachments: InstallConfiguration.java, mojo.patch
>
>
> When the {{installAtEnd}} configuration parameter is set to {{true}} on a 
> multimodule project with multiple class realms then because a different class 
> loaders creates instances of the {{InstallMojo}} class there will be muliple 
> instances of {{readyProjectsCounter}} and {{installRequests}}.
> However, because the end is determined by {{projectsReady = 
> readyProjectsCounter.incrementAndGet() == reactorProjects.size()}} it will 
> never complete as {{readyProjectsCounter}} will never equal the size 
> {{reactorProjects}} if even one project is executed in another class realm.
> {{maven-deploy-plugin}} partially solved this in MDEPLOY-193 by using 
> {{project.equals(reactorProjects.get(reactorProjects.size() - 1))}} instead.  
> However, the installation is a little more complex than the deploy as we need 
> to read the used the {{createChecksum}} and {{updateReleaseInfo}} 
> configuration parameters from each installed project - we can't store them 
> ahead of time because of the issue with the class realms, so we need to read 
> the plugin configurations before we can call 
> {{installProject(instalRequest)}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MINSTALL-102) installAtEnd does not install artifacts for multi-module with packaging maven-archetype

[Charles Honton (JIRA)]

[ 
https://issues.apache.org/jira/browse/MINSTALL-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16370901#comment-16370901
 ] 

Charles Honton commented on MINSTALL-102:
-

I suspect installAtEnd has same problems as deployAtEnd.  see MDEPLOY-200, 
MDEPLOY-224, MDEPLOY-225, and MDEPLOY-226, 

> installAtEnd does not install artifacts for multi-module with packaging 
> maven-archetype
> ---
>
> Key: MINSTALL-102
> URL: https://issues.apache.org/jira/browse/MINSTALL-102
> Project: Maven Install Plugin
>  Issue Type: Bug
>  Components: install:install
>Affects Versions: 2.5.1, 2.5.2
> Environment: Windows 7 / SLES11
>Reporter: Jörg Sesterhenn
>Assignee: Robert Scholte
>Priority: Major
> Attachments: test.zip, test2.zip
>
>
> InstallAtEnd does not install any artifacts for multi-module maven-archetype. 
> See attached minimal example (test.zip).
> Same error occurs for deployPlugin!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SUREFIRE-1478) VM Crash org.apache.maven.plugins:maven-surefire-plugin:2.12.4

[*$^¨%`£]

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

Olivier Lamy (*$^¨%`£) commented on SUREFIRE-1478:
--

Hi

Can you please try with a more recent version of surefire?

we are now up to 2.22.1

> VM Crash org.apache.maven.plugins:maven-surefire-plugin:2.12.4
> --
>
> Key: SUREFIRE-1478
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1478
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: JUnit 5.x support
>Affects Versions: 2.20.1
> Environment: Apache Maven 3.5.2 
> (138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T01:58:13-06:00)
> Maven home: C:\Program Files\apache-maven-3.5.2\bin\..
> Java version: 1.8.0_162, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_162\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Matt Sullivan
>Priority: Major
>  Labels: maven, newbie, windows
>
> Maven crashes with:
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test (default-test)
>  on project big-number
>  : Execution default-test of goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.12.4
>  :test failed: The forked VM terminated without saying properly goodbye. VM 
> crash or System.exit called ? -> [Help 1]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (SUREFIRE-1480) parallel tests may produce invalid .xml report

[Mark Lehky (JIRA)]

Mark Lehky created SUREFIRE-1480:


 Summary: parallel tests may produce invalid .xml report
 Key: SUREFIRE-1480
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1480
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Failsafe Plugin, Maven Surefire Plugin
Affects Versions: 2.20.1
Reporter: Mark Lehky


Relevant software:
 * Jenkins 2.108
 * Maven 3.??
 * JUnit 4.12
 * maven-failsafe-plugin 2.20.1 (I have seen this issue with surefire as well)

I have a testsuite (one JUnit class) that contains multiple tests (multiple 
JUnit methods), which are all run in parallel. Some of the tests may be ignore 
using JUnit {{Assume}}.

On occasion (not 100% reproducible), the resulting report will contain an entry 
like:
{noformat}
< message="Skip test!">
{noformat}
The correct entry, as is produced most of the time, should be:
{noformat}

{noformat}
The invalid formatted XML, when run in Jenkins, results in the test being 
flagged as failed, and Jenkins simply has the message: 
"TEST-xml.[failed-to-read]" (the dots are replaced with the correct 
filename!).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (MARCHETYPES-58) release all archetypes in a row

[JIRA]

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

Hervé Boutemy closed MARCHETYPES-58.

Resolution: Fixed
  Assignee: Hervé Boutemy

> release all archetypes in a row
> ---
>
> Key: MARCHETYPES-58
> URL: https://issues.apache.org/jira/browse/MARCHETYPES-58
> Project: Maven Archetype Bundles
>  Issue Type: Task
>  Components: Maven Archetype Archetype, Maven Plugin Archetype, Maven 
> Plugin Site Archetype, Maven Portlet Archetype, Maven Quickstart Archetype, 
> Maven Simple J2EE Archetype, Maven Simple Project Archetype, Maven Simple 
> Site Archetype, Maven Site Archetype, Maven Webapp Archetype
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
>Priority: Major
> Fix For: 1.3
>
>
> this will be easier for people to understand, and ease Git migration



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MPH-87) help:effective-pom/effective-settings uses platform encoding and garbles non-ASCII characters, emits invalid XML

[Michael Osipov (JIRA)]

[ 
https://issues.apache.org/jira/browse/MPH-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16370757#comment-16370757
 ] 

Michael Osipov commented on MPH-87:
---

Friends, I guess have solved the problem. A new snapshot has been deployed. The 
fix in branch MPH-87. If no one objects, I will merge in a week.

> help:effective-pom/effective-settings uses platform encoding and garbles 
> non-ASCII characters, emits invalid XML
> 
>
> Key: MPH-87
> URL: https://issues.apache.org/jira/browse/MPH-87
> Project: Maven Help Plugin
>  Issue Type: Bug
>  Components: effective-pom
>Affects Versions: 2.1.1
> Environment: Windows, MacOSX, Linux, Maven 3.0.4
>Reporter: Mirko Friedenhagen
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: mfriedenhagen-invalidpom-MPH-87-0-g42a5c31.zip
>
>
> As stated in http://www.w3.org/TR/REC-xml/#sec-guessing-no-ext-info XML files 
> without a BOM and without a XML encoding declaration should read the XML as 
> UTF-8. 
> {{help:effective-pom}} does use the platform encoding for writing the 
> effective-pom without emitting an appropriate XML encoding declaration in the 
> resulting XML file.
> I have created a small sample project (available at 
> https://github.com/mfriedenhagen/invalidpom, attached as ZIP) which will 
> reproduce the issue.
> While the parent pom 
> (https://raw.github.com/mfriedenhagen/invalidpom/master/pom.xml) has a XML 
> encoding declaration, 
> https://raw.github.com/mfriedenhagen/invalidpom/master/child-invalid/pom.xml 
> has none.
> Now running:
> {code}
> mvn -s settings.xml -gs settings.xml clean validate
> {code}
> will produce an invalid character for the developer name "Jörg" in 
> {{child-invalid}}. 
> Two workarounds are:
> * to include a XML encoding declaration as done in {{child-valid}}. 
> * to use {{JAVA_TOOL_OPTIONS}} on Windows as stated in 
> http://stackoverflow.com/a/623036/49132
> * to use {{MAVEN_OPTS=-Dfile.encoding=utf-8 mvn -s settings.xml -gs 
> settings.xml clean validate}}.
> Nonetheless I consider this a Major bug, as it clearly violates the 
> recommendations of W3C.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MPH-87) help:effective-pom/effective-settings uses platform encoding and garbles non-ASCII characters, emits invalid XML

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MPH-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16370746#comment-16370746
 ] 

Hudson commented on MPH-87:
---

Build succeeded in Jenkins: Maven TLP » maven-help-plugin » MPH-87 #2

See https://builds.apache.org/job/maven-box/job/maven-help-plugin/job/MPH-87/2/

> help:effective-pom/effective-settings uses platform encoding and garbles 
> non-ASCII characters, emits invalid XML
> 
>
> Key: MPH-87
> URL: https://issues.apache.org/jira/browse/MPH-87
> Project: Maven Help Plugin
>  Issue Type: Bug
>  Components: effective-pom
>Affects Versions: 2.1.1
> Environment: Windows, MacOSX, Linux, Maven 3.0.4
>Reporter: Mirko Friedenhagen
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: mfriedenhagen-invalidpom-MPH-87-0-g42a5c31.zip
>
>
> As stated in http://www.w3.org/TR/REC-xml/#sec-guessing-no-ext-info XML files 
> without a BOM and without a XML encoding declaration should read the XML as 
> UTF-8. 
> {{help:effective-pom}} does use the platform encoding for writing the 
> effective-pom without emitting an appropriate XML encoding declaration in the 
> resulting XML file.
> I have created a small sample project (available at 
> https://github.com/mfriedenhagen/invalidpom, attached as ZIP) which will 
> reproduce the issue.
> While the parent pom 
> (https://raw.github.com/mfriedenhagen/invalidpom/master/pom.xml) has a XML 
> encoding declaration, 
> https://raw.github.com/mfriedenhagen/invalidpom/master/child-invalid/pom.xml 
> has none.
> Now running:
> {code}
> mvn -s settings.xml -gs settings.xml clean validate
> {code}
> will produce an invalid character for the developer name "Jörg" in 
> {{child-invalid}}. 
> Two workarounds are:
> * to include a XML encoding declaration as done in {{child-valid}}. 
> * to use {{JAVA_TOOL_OPTIONS}} on Windows as stated in 
> http://stackoverflow.com/a/623036/49132
> * to use {{MAVEN_OPTS=-Dfile.encoding=utf-8 mvn -s settings.xml -gs 
> settings.xml clean validate}}.
> Nonetheless I consider this a Major bug, as it clearly violates the 
> recommendations of W3C.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MARCHETYPES-58) release all archetypes in a row

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MARCHETYPES-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16370743#comment-16370743
 ] 

Hudson commented on MARCHETYPES-58:
---

SUCCESS: Integrated in Jenkins build maven-archetypes #125 (See 
[https://builds.apache.org/job/maven-archetypes/125/])
[MARCHETYPES-58] release all archetypes in a row (hboutemy: 
[http://svn.apache.org/viewvc/?view=rev=1824918])
* (edit) maven-archetype-archetype/pom.xml
* (edit) maven-archetype-j2ee-simple/pom.xml
* (edit) maven-archetype-plugin-site/pom.xml
* (edit) maven-archetype-plugin/pom.xml
* (edit) maven-archetype-portlet/pom.xml
* (edit) maven-archetype-profiles/pom.xml
* (edit) maven-archetype-quickstart/pom.xml
* (edit) maven-archetype-simple/pom.xml
* (edit) maven-archetype-site-simple/pom.xml
* (edit) maven-archetype-site/pom.xml
* (edit) maven-archetype-webapp/pom.xml
* (edit) pom.xml
* (add) src
* (add) src/site
* (add) src/site/apt
* (add) src/site/apt/index.apt
* (add) src/site/resources
* (add) src/site/resources/download.cgi
* (add) src/site/site.xml
* (add) src/site/xdoc
* (add) src/site/xdoc/download.xml.vm


> release all archetypes in a row
> ---
>
> Key: MARCHETYPES-58
> URL: https://issues.apache.org/jira/browse/MARCHETYPES-58
> Project: Maven Archetype Bundles
>  Issue Type: Task
>  Components: Maven Archetype Archetype, Maven Plugin Archetype, Maven 
> Plugin Site Archetype, Maven Portlet Archetype, Maven Quickstart Archetype, 
> Maven Simple J2EE Archetype, Maven Simple Project Archetype, Maven Simple 
> Site Archetype, Maven Site Archetype, Maven Webapp Archetype
>Reporter: Hervé Boutemy
>Priority: Major
> Fix For: 1.3
>
>
> this will be easier for people to understand, and ease Git migration



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-6215) 'mvn --encrypt-password' doesn't prompt in Git Bash

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz commented on MNG-6215:
---

{{See [https://github.com/mintty/mintty/issues/244]}}

_The problem is common to all Cygwin terminals using pseudo terminal (pty) 
devices, which Cygwin implements using Windows pipes. The underlying reason is 
that Windows doesn't have an interface that would allow to emulate a console._

The same problem has other tools like Eclipse - The problem is beyond Maven 
tool.

Please use a different shell.

> 'mvn --encrypt-password' doesn't prompt in Git Bash
> ---
>
> Key: MNG-6215
> URL: https://issues.apache.org/jira/browse/MNG-6215
> Project: Maven
>  Issue Type: Bug
>  Components: Command Line
>Affects Versions: 3.3.9
> Environment: git version 2.12.2.windows.2
> jdk 8u111
> windows 7 pro
>Reporter: Alex Pintilie
>Priority: Major
> Fix For: 3.5.x-candidate
>
> Attachments: screenshot.jpg
>
>
> When I try to encrypt a password with {{mvn --encrypt-password}} in the Git 
> Bash, I get no prompt like in the windows command prompt. Instead I get some 
> empty curly braces {} (see screenshot).
> {{git version 2.12.2.windows.2}}
> Regards,
> Alex



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (MPOM-183) remove maven-archetype-bundles

[JIRA]

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

Hervé Boutemy closed MPOM-183.
--
Resolution: Fixed

> remove maven-archetype-bundles
> --
>
> Key: MPOM-183
> URL: https://issues.apache.org/jira/browse/MPOM-183
> Project: Maven POMs
>  Issue Type: Task
>  Components: maven-archeypes
>Affects Versions: MAVEN-31
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
>Priority: Major
> Fix For: MAVEN-32
>
>
> after MARCHETYPES-58, released as part of the archetypes



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MPOM-183) remove maven-archetype-bundles

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MPOM-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16370729#comment-16370729
 ] 

Hudson commented on MPOM-183:
-

Build succeeded in Jenkins: Maven TLP » maven-parent » master #68

See https://builds.apache.org/job/maven-box/job/maven-parent/job/master/68/

> remove maven-archetype-bundles
> --
>
> Key: MPOM-183
> URL: https://issues.apache.org/jira/browse/MPOM-183
> Project: Maven POMs
>  Issue Type: Task
>  Components: maven-archeypes
>Affects Versions: MAVEN-31
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
>Priority: Major
> Fix For: MAVEN-32
>
>
> after MARCHETYPES-58, released as part of the archetypes



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MPH-87) help:effective-pom/effective-settings uses platform encoding and garbles non-ASCII characters, emits invalid XML

[Michael Osipov (JIRA)]

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

Michael Osipov updated MPH-87:
--
Summary: help:effective-pom/effective-settings uses platform encoding and 
garbles non-ASCII characters, emits invalid XML  (was: help:effective-pom uses 
platform encoding and garbles non-ascii characters, emits invalid XML)

> help:effective-pom/effective-settings uses platform encoding and garbles 
> non-ASCII characters, emits invalid XML
> 
>
> Key: MPH-87
> URL: https://issues.apache.org/jira/browse/MPH-87
> Project: Maven Help Plugin
>  Issue Type: Bug
>  Components: effective-pom
>Affects Versions: 2.1.1
> Environment: Windows, MacOSX, Linux, Maven 3.0.4
>Reporter: Mirko Friedenhagen
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: mfriedenhagen-invalidpom-MPH-87-0-g42a5c31.zip
>
>
> As stated in http://www.w3.org/TR/REC-xml/#sec-guessing-no-ext-info XML files 
> without a BOM and without a XML encoding declaration should read the XML as 
> UTF-8. 
> {{help:effective-pom}} does use the platform encoding for writing the 
> effective-pom without emitting an appropriate XML encoding declaration in the 
> resulting XML file.
> I have created a small sample project (available at 
> https://github.com/mfriedenhagen/invalidpom, attached as ZIP) which will 
> reproduce the issue.
> While the parent pom 
> (https://raw.github.com/mfriedenhagen/invalidpom/master/pom.xml) has a XML 
> encoding declaration, 
> https://raw.github.com/mfriedenhagen/invalidpom/master/child-invalid/pom.xml 
> has none.
> Now running:
> {code}
> mvn -s settings.xml -gs settings.xml clean validate
> {code}
> will produce an invalid character for the developer name "Jörg" in 
> {{child-invalid}}. 
> Two workarounds are:
> * to include a XML encoding declaration as done in {{child-valid}}. 
> * to use {{JAVA_TOOL_OPTIONS}} on Windows as stated in 
> http://stackoverflow.com/a/623036/49132
> * to use {{MAVEN_OPTS=-Dfile.encoding=utf-8 mvn -s settings.xml -gs 
> settings.xml clean validate}}.
> Nonetheless I consider this a Major bug, as it clearly violates the 
> recommendations of W3C.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (MPH-87) help:effective-pom uses platform encoding and garbles non-ascii characters, emits invalid XML

[Michael Osipov (JIRA)]

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

Michael Osipov reassigned MPH-87:
-

Assignee: Michael Osipov

> help:effective-pom uses platform encoding and garbles non-ascii characters, 
> emits invalid XML
> -
>
> Key: MPH-87
> URL: https://issues.apache.org/jira/browse/MPH-87
> Project: Maven Help Plugin
>  Issue Type: Bug
>  Components: effective-pom
>Affects Versions: 2.1.1
> Environment: Windows, MacOSX, Linux, Maven 3.0.4
>Reporter: Mirko Friedenhagen
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: mfriedenhagen-invalidpom-MPH-87-0-g42a5c31.zip
>
>
> As stated in http://www.w3.org/TR/REC-xml/#sec-guessing-no-ext-info XML files 
> without a BOM and without a XML encoding declaration should read the XML as 
> UTF-8. 
> {{help:effective-pom}} does use the platform encoding for writing the 
> effective-pom without emitting an appropriate XML encoding declaration in the 
> resulting XML file.
> I have created a small sample project (available at 
> https://github.com/mfriedenhagen/invalidpom, attached as ZIP) which will 
> reproduce the issue.
> While the parent pom 
> (https://raw.github.com/mfriedenhagen/invalidpom/master/pom.xml) has a XML 
> encoding declaration, 
> https://raw.github.com/mfriedenhagen/invalidpom/master/child-invalid/pom.xml 
> has none.
> Now running:
> {code}
> mvn -s settings.xml -gs settings.xml clean validate
> {code}
> will produce an invalid character for the developer name "Jörg" in 
> {{child-invalid}}. 
> Two workarounds are:
> * to include a XML encoding declaration as done in {{child-valid}}. 
> * to use {{JAVA_TOOL_OPTIONS}} on Windows as stated in 
> http://stackoverflow.com/a/623036/49132
> * to use {{MAVEN_OPTS=-Dfile.encoding=utf-8 mvn -s settings.xml -gs 
> settings.xml clean validate}}.
> Nonetheless I consider this a Major bug, as it clearly violates the 
> recommendations of W3C.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MPH-87) help:effective-pom uses platform encoding and garbles non-ascii characters, emits invalid XML

[Michael Osipov (JIRA)]

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

Michael Osipov updated MPH-87:
--
Fix Version/s: 3.0.0

> help:effective-pom uses platform encoding and garbles non-ascii characters, 
> emits invalid XML
> -
>
> Key: MPH-87
> URL: https://issues.apache.org/jira/browse/MPH-87
> Project: Maven Help Plugin
>  Issue Type: Bug
>  Components: effective-pom
>Affects Versions: 2.1.1
> Environment: Windows, MacOSX, Linux, Maven 3.0.4
>Reporter: Mirko Friedenhagen
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: mfriedenhagen-invalidpom-MPH-87-0-g42a5c31.zip
>
>
> As stated in http://www.w3.org/TR/REC-xml/#sec-guessing-no-ext-info XML files 
> without a BOM and without a XML encoding declaration should read the XML as 
> UTF-8. 
> {{help:effective-pom}} does use the platform encoding for writing the 
> effective-pom without emitting an appropriate XML encoding declaration in the 
> resulting XML file.
> I have created a small sample project (available at 
> https://github.com/mfriedenhagen/invalidpom, attached as ZIP) which will 
> reproduce the issue.
> While the parent pom 
> (https://raw.github.com/mfriedenhagen/invalidpom/master/pom.xml) has a XML 
> encoding declaration, 
> https://raw.github.com/mfriedenhagen/invalidpom/master/child-invalid/pom.xml 
> has none.
> Now running:
> {code}
> mvn -s settings.xml -gs settings.xml clean validate
> {code}
> will produce an invalid character for the developer name "Jörg" in 
> {{child-invalid}}. 
> Two workarounds are:
> * to include a XML encoding declaration as done in {{child-valid}}. 
> * to use {{JAVA_TOOL_OPTIONS}} on Windows as stated in 
> http://stackoverflow.com/a/623036/49132
> * to use {{MAVEN_OPTS=-Dfile.encoding=utf-8 mvn -s settings.xml -gs 
> settings.xml clean validate}}.
> Nonetheless I consider this a Major bug, as it clearly violates the 
> recommendations of W3C.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (MPOM-183) remove maven-archetype-bundles

[JIRA]

Hervé Boutemy created MPOM-183:
--

 Summary: remove maven-archetype-bundles
 Key: MPOM-183
 URL: https://issues.apache.org/jira/browse/MPOM-183
 Project: Maven POMs
  Issue Type: Task
  Components: maven-archeypes
Affects Versions: MAVEN-31
Reporter: Hervé Boutemy
Assignee: Hervé Boutemy
 Fix For: MAVEN-32


after MARCHETYPES-58, released as part of the archetypes



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MANTRUN-206) Plugin fails with conditional property containing a Windows path.

[JIRA]

[ 
https://issues.apache.org/jira/browse/MANTRUN-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16370692#comment-16370692
 ] 

Guillaume Boué commented on MANTRUN-206:


I don't think this can be solved at the plugin level. Once the plugin sees the 
POM, the basedir is already replaced with its absolute value in the plugin 
configuration, and it would need to make the distinction between a real 
pattern, and something that should be escaped. This is not always possible (is 
{{\target}} the literal string or a tabulation character followed by arget?).

A possible solution is to escape the pattern manually:

{code:xml}

  

  
  

  

  


  

  

{code}

> Plugin fails with conditional property containing a Windows path.
> -
>
> Key: MANTRUN-206
> URL: https://issues.apache.org/jira/browse/MANTRUN-206
> Project: Maven Antrun Plugin
>  Issue Type: Bug
>Reporter: Robert Scholte
>Assignee: Guillaume Boué
>Priority: Major
>
> {code:xml}
> 
>   
>  value="${project.reporting.outputDirectory}/xsddoc">
>pattern="^${basedir}" />
> 
>   
> 
> {code}
> This fragment fails on Windows with something like:
> {noformat}
> Caused by: java.util.regex.PatternSyntaxException: Illegal/unsupported escape 
> sequence near index 4
> ^E:\java-workspace\apache-maven-doxia\maven-doxia\doxia-modules\doxia-module-fml
> ^
> at java.util.regex.Pattern.error (Pattern.java:1957)
> at java.util.regex.Pattern.escape (Pattern.java:2473)
> at java.util.regex.Pattern.atom (Pattern.java:2200)
> at java.util.regex.Pattern.sequence (Pattern.java:2132)
> at java.util.regex.Pattern.expr (Pattern.java:1998)
> at java.util.regex.Pattern.compile (Pattern.java:1698)
> at java.util.regex.Pattern. (Pattern.java:1351)
> at java.util.regex.Pattern.compile (Pattern.java:1054)
> at org.apache.tools.ant.util.regexp.Jdk14RegexpMatcher.getCompiledPattern 
> (Jdk14RegexpMatcher.java:67)
> at org.apache.tools.ant.util.regexp.Jdk14RegexpMatcher.matches 
> (Jdk14RegexpMatcher.java:94)
> at org.apache.tools.ant.taskdefs.condition.Matches.eval (Matches.java:117)
> at org.apache.tools.ant.taskdefs.ConditionTask.execute 
> (ConditionTask.java:120)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke 
> (NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke 
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:498)
> at org.apache.tools.ant.dispatch.DispatchUtils.execute 
> (DispatchUtils.java:106)
> at org.apache.tools.ant.TaskAdapter.execute (TaskAdapter.java:154)
> at org.apache.tools.ant.UnknownElement.execute (UnknownElement.java:292)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke 
> (NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke 
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:498)
> at org.apache.tools.ant.dispatch.DispatchUtils.execute 
> (DispatchUtils.java:106)
> at org.apache.tools.ant.Task.perform (Task.java:348)
> at org.apache.tools.ant.Target.execute (Target.java:435)
> at org.apache.tools.ant.Target.performTasks (Target.java:456)
> at org.apache.tools.ant.Project.executeSortedTargets (Project.java:1393)
> at org.apache.tools.ant.Project.executeTarget (Project.java:1364)
> at org.apache.maven.plugin.antrun.AntRunMojo.execute (AntRunMojo.java:313)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (MANTRUN-206) Plugin fails with conditional property containing a Windows path.

[JIRA]

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

Guillaume Boué reassigned MANTRUN-206:
--

Assignee: Guillaume Boué

> Plugin fails with conditional property containing a Windows path.
> -
>
> Key: MANTRUN-206
> URL: https://issues.apache.org/jira/browse/MANTRUN-206
> Project: Maven Antrun Plugin
>  Issue Type: Bug
>Reporter: Robert Scholte
>Assignee: Guillaume Boué
>Priority: Major
>
> {code:xml}
> 
>   
>  value="${project.reporting.outputDirectory}/xsddoc">
>pattern="^${basedir}" />
> 
>   
> 
> {code}
> This fragment fails on Windows with something like:
> {noformat}
> Caused by: java.util.regex.PatternSyntaxException: Illegal/unsupported escape 
> sequence near index 4
> ^E:\java-workspace\apache-maven-doxia\maven-doxia\doxia-modules\doxia-module-fml
> ^
> at java.util.regex.Pattern.error (Pattern.java:1957)
> at java.util.regex.Pattern.escape (Pattern.java:2473)
> at java.util.regex.Pattern.atom (Pattern.java:2200)
> at java.util.regex.Pattern.sequence (Pattern.java:2132)
> at java.util.regex.Pattern.expr (Pattern.java:1998)
> at java.util.regex.Pattern.compile (Pattern.java:1698)
> at java.util.regex.Pattern. (Pattern.java:1351)
> at java.util.regex.Pattern.compile (Pattern.java:1054)
> at org.apache.tools.ant.util.regexp.Jdk14RegexpMatcher.getCompiledPattern 
> (Jdk14RegexpMatcher.java:67)
> at org.apache.tools.ant.util.regexp.Jdk14RegexpMatcher.matches 
> (Jdk14RegexpMatcher.java:94)
> at org.apache.tools.ant.taskdefs.condition.Matches.eval (Matches.java:117)
> at org.apache.tools.ant.taskdefs.ConditionTask.execute 
> (ConditionTask.java:120)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke 
> (NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke 
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:498)
> at org.apache.tools.ant.dispatch.DispatchUtils.execute 
> (DispatchUtils.java:106)
> at org.apache.tools.ant.TaskAdapter.execute (TaskAdapter.java:154)
> at org.apache.tools.ant.UnknownElement.execute (UnknownElement.java:292)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke 
> (NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke 
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:498)
> at org.apache.tools.ant.dispatch.DispatchUtils.execute 
> (DispatchUtils.java:106)
> at org.apache.tools.ant.Task.perform (Task.java:348)
> at org.apache.tools.ant.Target.execute (Target.java:435)
> at org.apache.tools.ant.Target.performTasks (Target.java:456)
> at org.apache.tools.ant.Project.executeSortedTargets (Project.java:1393)
> at org.apache.tools.ant.Project.executeTarget (Project.java:1364)
> at org.apache.maven.plugin.antrun.AntRunMojo.execute (AntRunMojo.java:313)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (MARCHETYPES-58) release all archetypes in a row

[JIRA]

Hervé Boutemy created MARCHETYPES-58:


 Summary: release all archetypes in a row
 Key: MARCHETYPES-58
 URL: https://issues.apache.org/jira/browse/MARCHETYPES-58
 Project: Maven Archetype Bundles
  Issue Type: Task
  Components: Maven Archetype Archetype, Maven Plugin Archetype, Maven 
Plugin Site Archetype, Maven Portlet Archetype, Maven Quickstart Archetype, 
Maven Simple J2EE Archetype, Maven Simple Project Archetype, Maven Simple Site 
Archetype, Maven Site Archetype, Maven Webapp Archetype
Reporter: Hervé Boutemy
 Fix For: 1.3


this will be easier for people to understand, and ease Git migration



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (DOXIA-570) Unescaped links in xml based figureGraphics elements

[Sylwester Lachiewicz (JIRA)]

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

Sylwester Lachiewicz updated DOXIA-570:
---
Affects Version/s: 1.8

> Unescaped links in xml based figureGraphics elements
> 
>
> Key: DOXIA-570
> URL: https://issues.apache.org/jira/browse/DOXIA-570
> Project: Maven Doxia
>  Issue Type: Bug
>  Components: Modules
>Affects Versions: 1.8
>Reporter: Sylwester Lachiewicz
>Priority: Minor
>
> While testing newer version of maven-pdf-plugin i got exception
> {{Caused by: org.xml.sax.SAXParseException: The reference to entity "s" must 
> end with the ';' delimiter.}}
> for transformation from FO to PDF for team-list file. Output from the 
> reporting plugin has a image link for the Gravatar profile that contains 
> "?d=mm=60"
> Problem exists for all xml-based modules: FO, Docbook, XDoc, XHTML
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (SUREFIRE-1125) Running multiple methods via the `test` property does not work in junit47 provider

[George Snyder (JIRA)]

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

George Snyder edited comment on SUREFIRE-1125 at 2/20/18 9:25 PM:
--

Note, that if you can't or don't want to use a newer version which has this 
fixed, you can still avoid the problem (at least with some patterns) by 
including the full class name.  For example:
{noformat}
com.example.example.MyTest#myTest1, 
com.example.example.MyOtherTest#mySecondTest{noformat}
instead of
{noformat}
MyTest#myTest1, MyOtherTest#mySecondTest{noformat}


was (Author: snydergd):
Note, that if you can't or don't want to use a newer version which has this 
fixed, you can still avoid the problem (at least with some patterns) by 
including the full class name.  For example:
{noformat}
com.example.example.MyTest#myTest1, 
com.example.example.MyOtherTest#mySecondTest{noformat}

> Running multiple methods via the `test` property does not work in junit47 
> provider
> --
>
> Key: SUREFIRE-1125
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1125
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.18
>Reporter: Jörn Horstmann
>Assignee: Tibor Digana
>Priority: Minor
> Fix For: 2.19
>
>
> https://github.com/apache/maven-surefire/pull/75
> The syntax discussed in https://jira.codehaus.org/browse/SUREFIRE-745 and 
> documented in 
> http://maven.apache.org/surefire/maven-surefire-plugin/examples/single-test.html#Running_a_Set_of_Methods_in_a_Single_Test_Class
>  does not work when using the junit 4.7 provider.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SUREFIRE-1125) Running multiple methods via the `test` property does not work in junit47 provider

[George Snyder (JIRA)]

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

George Snyder commented on SUREFIRE-1125:
-

Note, that if you can't or don't want to use a newer version which has this 
fixed, you can still avoid the problem (at least with some patterns) by 
including the full class name.  For example:
{noformat}
com.example.example.MyTest#myTest1, 
com.example.example.MyOtherTest#mySecondTest{noformat}

> Running multiple methods via the `test` property does not work in junit47 
> provider
> --
>
> Key: SUREFIRE-1125
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1125
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.18
>Reporter: Jörn Horstmann
>Assignee: Tibor Digana
>Priority: Minor
> Fix For: 2.19
>
>
> https://github.com/apache/maven-surefire/pull/75
> The syntax discussed in https://jira.codehaus.org/browse/SUREFIRE-745 and 
> documented in 
> http://maven.apache.org/surefire/maven-surefire-plugin/examples/single-test.html#Running_a_Set_of_Methods_in_a_Single_Test_Class
>  does not work when using the junit 4.7 provider.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MPH-124) Show parameter aliases in describe goal

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MPH-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16370601#comment-16370601
 ] 

Hudson commented on MPH-124:


Build succeeded in Jenkins: Maven TLP » maven-help-plugin » master #5

See https://builds.apache.org/job/maven-box/job/maven-help-plugin/job/master/5/

> Show parameter aliases in describe goal
> ---
>
> Key: MPH-124
> URL: https://issues.apache.org/jira/browse/MPH-124
> Project: Maven Help Plugin
>  Issue Type: Improvement
>Affects Versions: 2.2
>Reporter: Ben Tatham
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.0.0
>
>
> {{mvn help:describe -Ddetail}} should show the alias as well.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (MPH-124) Show parameter aliases in describe goal

[Michael Osipov (JIRA)]

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

Michael Osipov closed MPH-124.
--
Resolution: Fixed

Fixed with 
[3bec8a68f3769b5bdaad8448dac62efbbb4fcd36|https://gitbox.apache.org/repos/asf?p=maven-help-plugin.git;a=commit;h=3bec8a68f3769b5bdaad8448dac62efbbb4fcd36].

> Show parameter aliases in describe goal
> ---
>
> Key: MPH-124
> URL: https://issues.apache.org/jira/browse/MPH-124
> Project: Maven Help Plugin
>  Issue Type: Improvement
>Affects Versions: 2.2
>Reporter: Ben Tatham
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.0.0
>
>
> {{mvn help:describe -Ddetail}} should show the alias as well.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (MPH-124) Show parameter aliases in describe goal

[Michael Osipov (JIRA)]

[ 
https://issues.apache.org/jira/browse/MPH-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16245928#comment-16245928
 ] 

Michael Osipov edited comment on MPH-124 at 2/20/18 8:44 PM:
-

GitHub user bentatham opened a pull request:

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

MPH-124: add alias to describe detail

Simply add the alias to the detail output, if it exists.

Sample output from one of our custom plugins:
{noformat}
[INFO] 'helios-dev:deploy-apollo' is a plugin goal (aka mojo).
Mojo: 'helios-dev:deploy-apollo'
helios-dev:deploy-apollo
  Description: (no description available)
  Implementation: ca.nanometrics.maven.helios.development.DeployApolloMojo
  Language: java

  Available parameters:

m_bboverlay (Default:
${project.build.directory}/bboverlay-tmp/${project.artifactId})
  Alias: bboverlay
  Required: true
  User property: bboverlay-tmp
  (no description available)

m_host
  Alias: host
  Required: true
  User property: sshhost
  (no description available)

m_keyFile (Default: ${user.home}/.ssh/id_rsa.helios)
  Alias: keyfile
  User property: keyfile
  (no description available)
{noformat}

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

$ git pull https://github.com/bentatham/maven-plugins 
feature/MPH-124-add-alias

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

https://github.com/apache/maven-plugins/pull/134.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 #134


commit 22aac4cb1934dc5999e614fe863fe15ffb722f52
Author: Ben Tatham 
Date:   2017-11-09T16:10:20Z

MPH-124: add alias to describe detail





was (Author: githubbot):
GitHub user bentatham opened a pull request:

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

MPH-124: add alias to describe detail

Simply add the alias to the detail output, if it exists.

Sample output from one of our custom plugins:
```
[INFO] 'helios-dev:deploy-apollo' is a plugin goal (aka mojo).
Mojo: 'helios-dev:deploy-apollo'
helios-dev:deploy-apollo
  Description: (no description available)
  Implementation: ca.nanometrics.maven.helios.development.DeployApolloMojo
  Language: java

  Available parameters:

m_bboverlay (Default:
${project.build.directory}/bboverlay-tmp/${project.artifactId})
  Alias: bboverlay
  Required: true
  User property: bboverlay-tmp
  (no description available)

m_host
  Alias: host
  Required: true
  User property: sshhost
  (no description available)

m_keyFile (Default: ${user.home}/.ssh/id_rsa.helios)
  Alias: keyfile
  User property: keyfile
  (no description available)
```

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

$ git pull https://github.com/bentatham/maven-plugins 
feature/MPH-124-add-alias

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

https://github.com/apache/maven-plugins/pull/134.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 #134


commit 22aac4cb1934dc5999e614fe863fe15ffb722f52
Author: Ben Tatham 
Date:   2017-11-09T16:10:20Z

MPH-124: add alias to describe detail




> Show parameter aliases in describe goal
> ---
>
> Key: MPH-124
> URL: https://issues.apache.org/jira/browse/MPH-124
> Project: Maven Help Plugin
>  Issue Type: Improvement
>Affects Versions: 2.2
>Reporter: Ben Tatham
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.0.0
>
>
> {{mvn help:describe -Ddetail}} should show the alias as well.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MPH-124) Show parameter aliases in describe goal

[Michael Osipov (JIRA)]

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

Michael Osipov updated MPH-124:
---
Affects Version/s: 2.2

> Show parameter aliases in describe goal
> ---
>
> Key: MPH-124
> URL: https://issues.apache.org/jira/browse/MPH-124
> Project: Maven Help Plugin
>  Issue Type: Improvement
>Affects Versions: 2.2
>Reporter: Ben Tatham
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.0.0
>
>
> {{mvn help:describe -Ddetail}} should show the alias as well.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (MPH-124) Show parameter aliases in describe goal

[Michael Osipov (JIRA)]

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

Michael Osipov reassigned MPH-124:
--

Assignee: Michael Osipov

> Show parameter aliases in describe goal
> ---
>
> Key: MPH-124
> URL: https://issues.apache.org/jira/browse/MPH-124
> Project: Maven Help Plugin
>  Issue Type: Improvement
>Affects Versions: 2.2
>Reporter: Ben Tatham
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.0.0
>
>
> {{mvn help:describe -Ddetail}} should show the alias as well.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MPH-124) Show parameter aliases in describe goal

[Michael Osipov (JIRA)]

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

Michael Osipov updated MPH-124:
---
Fix Version/s: 3.0.0

> Show parameter aliases in describe goal
> ---
>
> Key: MPH-124
> URL: https://issues.apache.org/jira/browse/MPH-124
> Project: Maven Help Plugin
>  Issue Type: Improvement
>Affects Versions: 2.2
>Reporter: Ben Tatham
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.0.0
>
>
> {{mvn help:describe -Ddetail}} should show the alias as well.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MPH-124) Show parameter aliases in describe goal

[Michael Osipov (JIRA)]

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

Michael Osipov updated MPH-124:
---
Summary: Show parameter aliases in describe goal  (was: Show parameter 
aliases in Describe.)

> Show parameter aliases in describe goal
> ---
>
> Key: MPH-124
> URL: https://issues.apache.org/jira/browse/MPH-124
> Project: Maven Help Plugin
>  Issue Type: Improvement
>Reporter: Ben Tatham
>Priority: Major
>
> {{mvn help:describe -Ddetail}} should show the alias as well.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-6323) Deadlock in multithreaded dependency resolution

[Hudson (JIRA)]

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

Hudson commented on MNG-6323:
-

Build succeeded in Jenkins: Maven TLP (wip) » maven » master #38

See https://builds.apache.org/job/maven-wip/job/maven/job/master/38/

> Deadlock in multithreaded dependency resolution
> ---
>
> Key: MNG-6323
> URL: https://issues.apache.org/jira/browse/MNG-6323
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.5.2
>Reporter: Ben Caradoc-Davies
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.5.3
>
> Attachments: geoserver-community-maven-hang-jstack-2.txt, 
> geoserver-community-maven-hang-jstack.txt
>
>
> Maven 3.5.2 multithreaded builds experience a deadlock not seen with Maven 
> 3.5.0.
> To reproduce the issue, clone GeoServer:
> {noformat}
> git clone https://github.com/geoserver/geoserver.git
> cd geoserver
> {noformat}
> Build GeoServer community modules with:
> {noformat}
> mvn -f src/community/pom.xml -B -T4 -U -Prelease -PcommunityRelease 
> -DskipTests clean install
> {noformat}
> Builds that normally take 2-4 minutes instead experience long hangs. 
> {{jstack}} output (attached) suggests a deadlock (two different hangs 
> attached). Some of the locks are in {{TIME_WAIT}} and eventually the build 
> completes after 30-45 minutes, but this is enough to cause builds on Travis 
> to be killed for their failure to output for ten minutes. (Travis upgraded to 
> Maven 3.5.2 a week ago.)
> I have only seen the failures with -U. The hang does not occur in 
> single-threaded builds. There are no "*.lock" files in the local repository 
> during the hang so the deadlocks are not mediated by the filesystem. CPU 
> utilisation is zero suggesting a deadlock not a livelock.
> See also discussion on the geoserver-devel mailing list: 
> http://osgeo-org.1560.x6.nabble.com/Travis-failures-started-with-new-trusty-images-td5346836.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (MNG-6323) Deadlock in multithreaded dependency resolution

[Robert Scholte (JIRA)]

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

Robert Scholte closed MNG-6323.
---
   Resolution: Fixed
Fix Version/s: (was: 3.5.3-candidate)
   3.5.3

Fixed in 
[91d1edf14e0ed198c917efeddd0b8241980ec0ed|http://git-wip-us.apache.org/repos/asf/maven/commit/91d1edf1]

> Deadlock in multithreaded dependency resolution
> ---
>
> Key: MNG-6323
> URL: https://issues.apache.org/jira/browse/MNG-6323
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.5.2
>Reporter: Ben Caradoc-Davies
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.5.3
>
> Attachments: geoserver-community-maven-hang-jstack-2.txt, 
> geoserver-community-maven-hang-jstack.txt
>
>
> Maven 3.5.2 multithreaded builds experience a deadlock not seen with Maven 
> 3.5.0.
> To reproduce the issue, clone GeoServer:
> {noformat}
> git clone https://github.com/geoserver/geoserver.git
> cd geoserver
> {noformat}
> Build GeoServer community modules with:
> {noformat}
> mvn -f src/community/pom.xml -B -T4 -U -Prelease -PcommunityRelease 
> -DskipTests clean install
> {noformat}
> Builds that normally take 2-4 minutes instead experience long hangs. 
> {{jstack}} output (attached) suggests a deadlock (two different hangs 
> attached). Some of the locks are in {{TIME_WAIT}} and eventually the build 
> completes after 30-45 minutes, but this is enough to cause builds on Travis 
> to be killed for their failure to output for ten minutes. (Travis upgraded to 
> Maven 3.5.2 a week ago.)
> I have only seen the failures with -U. The hang does not occur in 
> single-threaded builds. There are no "*.lock" files in the local repository 
> during the hang so the deadlocks are not mediated by the filesystem. CPU 
> utilisation is zero suggesting a deadlock not a livelock.
> See also discussion on the geoserver-devel mailing list: 
> http://osgeo-org.1560.x6.nabble.com/Travis-failures-started-with-new-trusty-images-td5346836.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] mattnelson commented on issue #1: fix DeployAtEnd failures

[GitBox]

mattnelson commented on issue #1: fix DeployAtEnd failures
URL: https://github.com/apache/maven-deploy-plugin/pull/1#issuecomment-367049186
 
 
   > Same PR as apache/maven-plugins#138.
   
   Interested in getting this fix merged.
   
   @khmarbaise Which repo should be used? I have an open PR myself on 
apache/maven-plugins because I didn't realize this repo existed.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (MASSEMBLY-675) Maven Assembly packaging wildcard-excluded dependencies

[Hudson (JIRA)]

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

Hudson commented on MASSEMBLY-675:
--

Build succeeded in Jenkins: Maven TLP » maven-assembly-plugin » master #5

See 
https://builds.apache.org/job/maven-box/job/maven-assembly-plugin/job/master/5/

> Maven Assembly packaging wildcard-excluded dependencies
> ---
>
> Key: MASSEMBLY-675
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-675
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.4
> Environment: Apache Maven 3.1.1
> Java version: 1.7.0_45, vendor: Oracle Corporation
> OS name: "mac os x", version: "10.8.4", arch: "x86_64", family: "mac"
>Reporter: Frank Wilson
>Assignee: Guillaume Boué
>Priority: Major
> Fix For: 3.1.1
>
> Attachments: massembly-675.zip
>
>
> Version 2.4 ignores wildcard exclusions in POM dependencies
> Example (perhaps contrived - but easy to setup):
> When a pom declares a dependency such as closure-compiler and for some reason 
> we do not want to pull its dependencies in we could declare this in our POM, 
> without having to know what those dependencies are:
>   
> 
>   com.google.javascript
>   closure-compiler
>   v20131014
>   
> 
>   *
>   *
> 
>   
> 
>   
> This is a valid use of the exclusion feature as per [Maven 
> Confluence|http://docs.codehaus.org/display/MAVENUSER/wildcard+exclusion+for+artifact+dependencies],
>  [MNG-3832|https://jira.codehaus.org/browse/MNG-3832]. False warning about 
> wildcards were 
> [fixed|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=65c135d5]
>  in Git about 10 days ago  
> Here is the assembly descriptor:
> 
>   bin
>   
> dir
>   
>   false
>   
> 
>   
> 
> We expect to only find the current project artifact and the closure-compiler 
> JAR in our directory assembly. However the assembly plugin ignores our POM 
> directive and includes the closure-compilers dependencies anyway!
> Steps to reproduce are:
> $ unzip massembly-675.zip
> $ cd massembly-675
> $ mvn clean install
> $ ls target/massembly-675-1-bin
> args4j-2.0.16.jar  json-20090211.jar  
> protobuf-java-2.4.1.jar
> closure-compiler-v20131014.jar jsr305-1.3.9.jar
> guava-15.0.jar massembly-675-1.jar
> *Notice that the excluded jars are included in the assembly*
> I would expect to only see the following JARs.
> * closure-compiler-v20131014.jar
> * massembly-675-1.jar



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (MASSEMBLY-675) Maven Assembly packaging wildcard-excluded dependencies

[JIRA]

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

Guillaume Boué closed MASSEMBLY-675.

   Resolution: Fixed
 Assignee: Guillaume Boué
Fix Version/s: 3.1.1

> Maven Assembly packaging wildcard-excluded dependencies
> ---
>
> Key: MASSEMBLY-675
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-675
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.4
> Environment: Apache Maven 3.1.1
> Java version: 1.7.0_45, vendor: Oracle Corporation
> OS name: "mac os x", version: "10.8.4", arch: "x86_64", family: "mac"
>Reporter: Frank Wilson
>Assignee: Guillaume Boué
>Priority: Major
> Fix For: 3.1.1
>
> Attachments: massembly-675.zip
>
>
> Version 2.4 ignores wildcard exclusions in POM dependencies
> Example (perhaps contrived - but easy to setup):
> When a pom declares a dependency such as closure-compiler and for some reason 
> we do not want to pull its dependencies in we could declare this in our POM, 
> without having to know what those dependencies are:
>   
> 
>   com.google.javascript
>   closure-compiler
>   v20131014
>   
> 
>   *
>   *
> 
>   
> 
>   
> This is a valid use of the exclusion feature as per [Maven 
> Confluence|http://docs.codehaus.org/display/MAVENUSER/wildcard+exclusion+for+artifact+dependencies],
>  [MNG-3832|https://jira.codehaus.org/browse/MNG-3832]. False warning about 
> wildcards were 
> [fixed|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=65c135d5]
>  in Git about 10 days ago  
> Here is the assembly descriptor:
> 
>   bin
>   
> dir
>   
>   false
>   
> 
>   
> 
> We expect to only find the current project artifact and the closure-compiler 
> JAR in our directory assembly. However the assembly plugin ignores our POM 
> directive and includes the closure-compilers dependencies anyway!
> Steps to reproduce are:
> $ unzip massembly-675.zip
> $ cd massembly-675
> $ mvn clean install
> $ ls target/massembly-675-1-bin
> args4j-2.0.16.jar  json-20090211.jar  
> protobuf-java-2.4.1.jar
> closure-compiler-v20131014.jar jsr305-1.3.9.jar
> guava-15.0.jar massembly-675-1.jar
> *Notice that the excluded jars are included in the assembly*
> I would expect to only see the following JARs.
> * closure-compiler-v20131014.jar
> * massembly-675-1.jar



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MASSEMBLY-675) Maven Assembly packaging wildcard-excluded dependencies

[JIRA]

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

Guillaume Boué commented on MASSEMBLY-675:
--

Fixed with initial PR in 
[b0cf85db9c466d42a4d39f46634ad49cbb784d8c|https://gitbox.apache.org/repos/asf?p=maven-assembly-plugin.git;a=commit;h=b0cf85db9c466d42a4d39f46634ad49cbb784d8c]
 and additional 
[78faddf88b1537bc5c61ba74cdb2b227416152b6|https://gitbox.apache.org/repos/asf?p=maven-assembly-plugin.git;a=commit;h=78faddf88b1537bc5c61ba74cdb2b227416152b6].

> Maven Assembly packaging wildcard-excluded dependencies
> ---
>
> Key: MASSEMBLY-675
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-675
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.4
> Environment: Apache Maven 3.1.1
> Java version: 1.7.0_45, vendor: Oracle Corporation
> OS name: "mac os x", version: "10.8.4", arch: "x86_64", family: "mac"
>Reporter: Frank Wilson
>Priority: Major
> Fix For: 3.1.1
>
> Attachments: massembly-675.zip
>
>
> Version 2.4 ignores wildcard exclusions in POM dependencies
> Example (perhaps contrived - but easy to setup):
> When a pom declares a dependency such as closure-compiler and for some reason 
> we do not want to pull its dependencies in we could declare this in our POM, 
> without having to know what those dependencies are:
>   
> 
>   com.google.javascript
>   closure-compiler
>   v20131014
>   
> 
>   *
>   *
> 
>   
> 
>   
> This is a valid use of the exclusion feature as per [Maven 
> Confluence|http://docs.codehaus.org/display/MAVENUSER/wildcard+exclusion+for+artifact+dependencies],
>  [MNG-3832|https://jira.codehaus.org/browse/MNG-3832]. False warning about 
> wildcards were 
> [fixed|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=65c135d5]
>  in Git about 10 days ago  
> Here is the assembly descriptor:
> 
>   bin
>   
> dir
>   
>   false
>   
> 
>   
> 
> We expect to only find the current project artifact and the closure-compiler 
> JAR in our directory assembly. However the assembly plugin ignores our POM 
> directive and includes the closure-compilers dependencies anyway!
> Steps to reproduce are:
> $ unzip massembly-675.zip
> $ cd massembly-675
> $ mvn clean install
> $ ls target/massembly-675-1-bin
> args4j-2.0.16.jar  json-20090211.jar  
> protobuf-java-2.4.1.jar
> closure-compiler-v20131014.jar jsr305-1.3.9.jar
> guava-15.0.jar massembly-675-1.jar
> *Notice that the excluded jars are included in the assembly*
> I would expect to only see the following JARs.
> * closure-compiler-v20131014.jar
> * massembly-675-1.jar



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MASSEMBLY-675) Maven Assembly packaging wildcard-excluded dependencies

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MASSEMBLY-675:
--

asfgit closed pull request #2: [MASSEMBLY-675] Require maven to solve 
dependencies instead of buildi…
URL: https://github.com/apache/maven-assembly-plugin/pull/2
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git 
a/src/main/java/org/apache/maven/plugins/assembly/artifact/DefaultDependencyResolver.java
 
b/src/main/java/org/apache/maven/plugins/assembly/artifact/DefaultDependencyResolver.java
index 741b19d8..936e250d 100644
--- 
a/src/main/java/org/apache/maven/plugins/assembly/artifact/DefaultDependencyResolver.java
+++ 
b/src/main/java/org/apache/maven/plugins/assembly/artifact/DefaultDependencyResolver.java
@@ -20,20 +20,14 @@
  */
 
 import java.util.ArrayList;
-import java.util.Collections;
 import java.util.HashSet;
 import java.util.LinkedHashMap;
-import java.util.LinkedHashSet;
 import java.util.List;
 import java.util.Map;
 import java.util.Set;
 
 import org.apache.maven.artifact.Artifact;
 import org.apache.maven.artifact.repository.ArtifactRepository;
-import org.apache.maven.artifact.resolver.ArtifactResolutionRequest;
-import org.apache.maven.artifact.resolver.ArtifactResolutionResult;
-import org.apache.maven.artifact.resolver.MultipleArtifactsNotFoundException;
-import org.apache.maven.artifact.resolver.filter.ArtifactFilter;
 import org.apache.maven.plugins.assembly.AssemblerConfigurationSource;
 import org.apache.maven.plugins.assembly.archive.ArchiveCreationException;
 import org.apache.maven.plugins.assembly.archive.phase.ModuleSetAssemblyPhase;
@@ -49,7 +43,6 @@
 import org.apache.maven.project.ProjectBuildingRequest;
 import org.apache.maven.repository.RepositorySystem;
 import org.apache.maven.shared.artifact.filter.resolve.ScopeFilter;
-import 
org.apache.maven.shared.artifact.filter.resolve.transform.ArtifactIncludeFilterTransformer;
 import org.apache.maven.shared.artifact.resolve.ArtifactResult;
 import 
org.apache.maven.shared.dependencies.resolve.DependencyResolverException;
 import org.codehaus.plexus.component.annotations.Component;
@@ -93,43 +86,28 @@
currentProject );
 updateModuleSetResolutionRequirements( assemblyId, moduleSet, 
dependencySet, info, configSource );
 
-resolve( assembly, configSource, result, dependencySet, info );
+result.put( dependencySet, resolve( info, currentProject ) );
 
 }
 return result;
 }
 
-private void resolve( Assembly assembly, AssemblerConfigurationSource 
configSource,
-  Map result, 
DependencySet dependencySet,
-  ResolutionManagementInfo info )
-throws DependencyResolutionException
+private Set resolve( ResolutionManagementInfo info, MavenProject 
project )
 {
-Set artifacts;
-if ( info.isResolutionRequired() )
+Set artifacts = new HashSet<>();
+if ( info.isResolvedTransitively() )
 {
-final List repos =
-aggregateRemoteArtifactRepositories( 
configSource.getRemoteRepositories(), info.getEnabledProjects() );
-
-artifacts = info.getArtifacts();
-if ( info.isResolvedTransitively() )
-{
-getLogger().debug( "Resolving project dependencies 
transitively." );
-
-ArtifactFilter filter = new 
ArtifactIncludeFilterTransformer().transform( info.getScopeFilter() );
-artifacts = resolveTransitively( artifacts, repos, filter, 
configSource );
-}
-else
-{
-getLogger().debug( "Resolving project dependencies ONLY. "
-   + "Transitive dependencies WILL NOT be 
included in the results." );
-artifacts = resolveNonTransitively( assembly, artifacts, 
configSource, repos );
-}
+getLogger().debug( "Resolving project dependencies transitively." 
);
+artifacts = project.getArtifacts();
 }
 else
 {
-artifacts = new HashSet();
+getLogger().debug( "Resolving project dependencies ONLY. "
++ "Transitive dependencies WILL NOT be included in the 
results." );
+artifacts = project.getDependencyArtifacts();
 }
-result.put( dependencySet, artifacts );
+
+return artifacts;
 }
 
 @Override
@@ -152,114 +130,29 @@ private void resolve( Assembly assembly, 
AssemblerConfigurationSource 

[GitHub] asfgit closed pull request #2: [MASSEMBLY-675] Require maven to solve dependencies instead of buildi?

[GitBox]

asfgit closed pull request #2: [MASSEMBLY-675] Require maven to solve 
dependencies instead of buildi?
URL: https://github.com/apache/maven-assembly-plugin/pull/2
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git 
a/src/main/java/org/apache/maven/plugins/assembly/artifact/DefaultDependencyResolver.java
 
b/src/main/java/org/apache/maven/plugins/assembly/artifact/DefaultDependencyResolver.java
index 741b19d8..936e250d 100644
--- 
a/src/main/java/org/apache/maven/plugins/assembly/artifact/DefaultDependencyResolver.java
+++ 
b/src/main/java/org/apache/maven/plugins/assembly/artifact/DefaultDependencyResolver.java
@@ -20,20 +20,14 @@
  */
 
 import java.util.ArrayList;
-import java.util.Collections;
 import java.util.HashSet;
 import java.util.LinkedHashMap;
-import java.util.LinkedHashSet;
 import java.util.List;
 import java.util.Map;
 import java.util.Set;
 
 import org.apache.maven.artifact.Artifact;
 import org.apache.maven.artifact.repository.ArtifactRepository;
-import org.apache.maven.artifact.resolver.ArtifactResolutionRequest;
-import org.apache.maven.artifact.resolver.ArtifactResolutionResult;
-import org.apache.maven.artifact.resolver.MultipleArtifactsNotFoundException;
-import org.apache.maven.artifact.resolver.filter.ArtifactFilter;
 import org.apache.maven.plugins.assembly.AssemblerConfigurationSource;
 import org.apache.maven.plugins.assembly.archive.ArchiveCreationException;
 import org.apache.maven.plugins.assembly.archive.phase.ModuleSetAssemblyPhase;
@@ -49,7 +43,6 @@
 import org.apache.maven.project.ProjectBuildingRequest;
 import org.apache.maven.repository.RepositorySystem;
 import org.apache.maven.shared.artifact.filter.resolve.ScopeFilter;
-import 
org.apache.maven.shared.artifact.filter.resolve.transform.ArtifactIncludeFilterTransformer;
 import org.apache.maven.shared.artifact.resolve.ArtifactResult;
 import 
org.apache.maven.shared.dependencies.resolve.DependencyResolverException;
 import org.codehaus.plexus.component.annotations.Component;
@@ -93,43 +86,28 @@
currentProject );
 updateModuleSetResolutionRequirements( assemblyId, moduleSet, 
dependencySet, info, configSource );
 
-resolve( assembly, configSource, result, dependencySet, info );
+result.put( dependencySet, resolve( info, currentProject ) );
 
 }
 return result;
 }
 
-private void resolve( Assembly assembly, AssemblerConfigurationSource 
configSource,
-  Map result, 
DependencySet dependencySet,
-  ResolutionManagementInfo info )
-throws DependencyResolutionException
+private Set resolve( ResolutionManagementInfo info, MavenProject 
project )
 {
-Set artifacts;
-if ( info.isResolutionRequired() )
+Set artifacts = new HashSet<>();
+if ( info.isResolvedTransitively() )
 {
-final List repos =
-aggregateRemoteArtifactRepositories( 
configSource.getRemoteRepositories(), info.getEnabledProjects() );
-
-artifacts = info.getArtifacts();
-if ( info.isResolvedTransitively() )
-{
-getLogger().debug( "Resolving project dependencies 
transitively." );
-
-ArtifactFilter filter = new 
ArtifactIncludeFilterTransformer().transform( info.getScopeFilter() );
-artifacts = resolveTransitively( artifacts, repos, filter, 
configSource );
-}
-else
-{
-getLogger().debug( "Resolving project dependencies ONLY. "
-   + "Transitive dependencies WILL NOT be 
included in the results." );
-artifacts = resolveNonTransitively( assembly, artifacts, 
configSource, repos );
-}
+getLogger().debug( "Resolving project dependencies transitively." 
);
+artifacts = project.getArtifacts();
 }
 else
 {
-artifacts = new HashSet();
+getLogger().debug( "Resolving project dependencies ONLY. "
++ "Transitive dependencies WILL NOT be included in the 
results." );
+artifacts = project.getDependencyArtifacts();
 }
-result.put( dependencySet, artifacts );
+
+return artifacts;
 }
 
 @Override
@@ -152,114 +130,29 @@ private void resolve( Assembly assembly, 
AssemblerConfigurationSource configSour

configSource.getMavenSession().getProjectBuildingRequest(),
currentProject );
 
-resolve( assembly, configSource, 

[jira] [Updated] (MASSEMBLY-877) give priority to module files when using jar-with-dependencies descriptor

[Simon (JIRA)]

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

Simon updated MASSEMBLY-877:

Description: 
Currently, when you create an uber jar using {{jar-with-dependencies}} 
descriptor if there is resource duplicates between current module and 
dependencies there is no guarantee the module one will be chosen.

E.g. :
 module A depends on module B.
 module A and module B contains a configuration file with the same name/ same 
path.

If I build A using jar-with-dependencies descriptor I have no guarantee my 
assembly will contains the configuration file of A.

I think this is because jar-with-dependencies use 
true and so there is no priority 
between the module and its dependencies.

A solution could be to change the descriptor and use something like this :
{code:xml}
http://maven.apache.org/ASSEMBLY/2.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/ASSEMBLY/2.0.0 
http://maven.apache.org/xsd/assembly-2.0.0.xsd;>
jar-with-dependencies

jar

false


${project.build.outputDirectory}





/
false
true
runtime



{code}
As FileSet have priority on dependencySet, it should do the tricks.

Does it make sense ?

  was:
Currently, when you create an uber jar using {{jar-with-dependencies}} 
descriptor if there is resource duplicates between current module and 
dependencies there is no guarantee the module one will be chosen.

E.g. :
 module A depends on module B.
 module A and module B contains a configuration file with the same name/ same 
path.

If I build A using jar-with-dependencies descriptor I have no guarantee my 
assembly will contains the configuration file of A.

I think this is because jar-with-dependencies use 
true and so there is no priority 
between the module and its dependencies.

A solution could be to change the descriptor and use something like this :
{code:xml}
http://maven.apache.org/ASSEMBLY/2.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/ASSEMBLY/2.0.0 
http://maven.apache.org/xsd/assembly-2.0.0.xsd;>
jar-with-dependencies

jar

false


${project.build.outputDirectory}
/




/
false
true
runtime



{code}
As FileSet have priority on dependencySet, it should do the tricks.

Does it make sense ?


> give priority to module files when using jar-with-dependencies descriptor
> -
>
> Key: MASSEMBLY-877
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-877
> Project: Maven Assembly Plugin
>  Issue Type: Improvement
>  Components: component descriptor
>Reporter: Simon
>Priority: Major
>
> Currently, when you create an uber jar using {{jar-with-dependencies}} 
> descriptor if there is resource duplicates between current module and 
> dependencies there is no guarantee the module one will be chosen.
> E.g. :
>  module A depends on module B.
>  module A and module B contains a configuration file with the same name/ same 
> path.
> If I build A using jar-with-dependencies descriptor I have no guarantee my 
> assembly will contains the configuration file of A.
> I think this is because jar-with-dependencies use 
> true and so there is no priority 
> between the module and its dependencies.
> A solution could be to change the descriptor and use something like this :
> {code:xml}
> http://maven.apache.org/ASSEMBLY/2.0.0;
>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>   xsi:schemaLocation="http://maven.apache.org/ASSEMBLY/2.0.0 
> http://maven.apache.org/xsd/assembly-2.0.0.xsd;>
>   jar-with-dependencies
>   
>   jar
>   
>   false
>   
>   
>   ${project.build.outputDirectory}
>   
>   
>   
>   
>   
>   /
>   false
>   true
>   runtime
>   
>   
> 
> {code}
> As FileSet have priority on dependencySet, it should do the tricks.
> Does it make sense ?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MNG-6366) Improve message warning

[Michel Barret (JIRA)]

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

Michel Barret updated MNG-6366:
---
Description: 
When a maven display message like "File encoding has not been set", it can be 
usefull to display what is the name of configuration to fix it. Instead:

{{[WARNING] File encoding has not been set, using platform encoding UTF-8, i.e. 
build is platform dependent!}}

we can have:

{{[WARNING] File encoding has not been set, using platform encoding UTF-8, i.e. 
build is platform dependent!}}
{{[WARNING] Maybe you should set the configuration: 
project.reporting.outputEncoding}}

{{It can be usefull!}}

  was:
When a maven display message like "File encoding has not been set", it can be 
usefull to display what is the name of configuration to fix it. Instead:

{{[WARNING] File encoding has not been set, using platform encoding UTF-8, i.e. 
build is platform dependent!}}

we can have:

{{[WARNING] File encoding has not been set, using platform encoding UTF-8, i.e. 
build is platform dependent!}}
{{ [WARNING] Maybe you should set the configuration: 
project.reporting.outputEncoding}}

 

{{It can be usefull!}}


> Improve message warning
> ---
>
> Key: MNG-6366
> URL: https://issues.apache.org/jira/browse/MNG-6366
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.5.2
>Reporter: Michel Barret
>Priority: Trivial
>
> When a maven display message like "File encoding has not been set", it can be 
> usefull to display what is the name of configuration to fix it. Instead:
> {{[WARNING] File encoding has not been set, using platform encoding UTF-8, 
> i.e. build is platform dependent!}}
> we can have:
> {{[WARNING] File encoding has not been set, using platform encoding UTF-8, 
> i.e. build is platform dependent!}}
> {{[WARNING] Maybe you should set the configuration: 
> project.reporting.outputEncoding}}
> {{It can be usefull!}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (MNG-6365) Improve message warning

[Michel Barret (JIRA)]

Michel Barret created MNG-6365:
--

 Summary: Improve message warning
 Key: MNG-6365
 URL: https://issues.apache.org/jira/browse/MNG-6365
 Project: Maven
  Issue Type: Bug
Affects Versions: 3.5.2
Reporter: Michel Barret


When a maven display message like "File encoding has not been set", it can be 
usefull to display what is the name of configuration to fix it. Instead:

{{[WARNING] File encoding has not been set, using platform encoding UTF-8, i.e. 
build is platform dependent!}}

we can have:

{{[WARNING] File encoding has not been set, using platform encoding UTF-8, i.e. 
build is platform dependent!}}
{{ [WARNING] Maybe you should set the configuration: 
project.reporting.outputEncoding}}

 

{{It can be usefull!}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (MNG-6366) Improve message warning

[Michel Barret (JIRA)]

Michel Barret created MNG-6366:
--

 Summary: Improve message warning
 Key: MNG-6366
 URL: https://issues.apache.org/jira/browse/MNG-6366
 Project: Maven
  Issue Type: Bug
Affects Versions: 3.5.2
Reporter: Michel Barret


When a maven display message like "File encoding has not been set", it can be 
usefull to display what is the name of configuration to fix it. Instead:

{{[WARNING] File encoding has not been set, using platform encoding UTF-8, i.e. 
build is platform dependent!}}

we can have:

{{[WARNING] File encoding has not been set, using platform encoding UTF-8, i.e. 
build is platform dependent!}}
{{ [WARNING] Maybe you should set the configuration: 
project.reporting.outputEncoding}}

 

{{It can be usefull!}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (WAGON-497) ScmWagon.put() strips parent dirs from the target path, if they already exist in SCM

[Ilya Basin (JIRA)]

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

Ilya Basin updated WAGON-497:
-
Description: 
Here're the symptoms of the bug:
 ScmCvsExeWagonTest.testWagonGetFileList() wants to checkin multiple files into 
"/file-list/".
 When the test repo is fresh, only the first file is checked in correctly. All 
other files are checked into the repo root.

Reason (and why it works fine with SVN):

In ScmWagon.checkOut() targetName is split to existing parth an non-existing 
part.

in case of svn:
 - checks out repoUrl + existingPart
 - mkdirs missingPart
 - return missingPart

the caller copies the new file into coDir/ + missingPart/

on second put() all dirs exist
 - checks out repoUrl + allPart
 - return empty string

the caller copies the new file into coDir/
 in case of cvs (on second put()):
 - checks out repoUrl WITHOUT allPart
 - returns empty string
 the caller copies the new file into coDir/

My current goal is to re-enable ScmCvsExeWagonTest. There are numerous bugs in 
wagon-scm and fixing just one is not enough to run even a single test case.

However, the proposed pull request will let you reach the point in 
[WagonTestCase#testWagonGetFileList()|https://github.com/apache/maven-wagon/blob/be94400731575f54ff537ec90359460f42a561cc/wagon-provider-test/src/main/java/org/apache/maven/wagon/WagonTestCase.java#L741]
 when all test files are checked in correctly.

UPD: The test case "testWagon" which could reveal that is disabled by mistake: 
it runs only if supportsGetIfNewer(), but we don't call getIfNewer() there.

UPD2: the cvs rls command is not widely supported, but ScmWagon cannot checkout 
when list() unsupported: it throws "Failed to create directory ", although the 
directory already exists.

  was:
Here're the symptoms of the bug:
 ScmCvsExeWagonTest.testWagonGetFileList() wants to checkin multiple files into 
"/file-list/".
 When the test repo is fresh, only the first file is checked in correctly. All 
other files are checked into the repo root.

Reason (and why it works fine with SVN):

In ScmWagon.checkOut() targetName is split to existing parth an non-existing 
part.

in case of svn:
 - checks out repoUrl + existingPart
 - mkdirs missingPart
 - return missingPart

the caller copies the new file into coDir/ + missingPart/

on second put() all dirs exist
 - checks out repoUrl + allPart
 - return empty string

the caller copies the new file into coDir/
 in case of cvs (on second put()):
 - checks out repoUrl WITHOUT allPart
 - returns empty string
 the caller copies the new file into coDir/

My current goal is to re-enable ScmCvsExeWagonTest. There are numerous bugs in 
wagon-scm and fixing just one is not enough to run even a single test case.

However, the proposed pull request will let you reach the point in 
[WagonTestCase#testWagonGetFileList()|https://github.com/apache/maven-wagon/blob/be94400731575f54ff537ec90359460f42a561cc/wagon-provider-test/src/main/java/org/apache/maven/wagon/WagonTestCase.java#L741]
 when all test files are checked in correctly.

UPD: The test case "testWagon" which could reveal that is disabled by mistake: 
it runs only if supportsGetIfNewer(), but we don't call getIfNewer() there.


> ScmWagon.put() strips parent dirs from the target path, if they already exist 
> in SCM
> 
>
> Key: WAGON-497
> URL: https://issues.apache.org/jira/browse/WAGON-497
> Project: Maven Wagon
>  Issue Type: Bug
>  Components: wagon-scm
>Affects Versions: 3.0.0, 3.0.1
>Reporter: Ilya Basin
>Priority: Major
>
> Here're the symptoms of the bug:
>  ScmCvsExeWagonTest.testWagonGetFileList() wants to checkin multiple files 
> into "/file-list/".
>  When the test repo is fresh, only the first file is checked in correctly. 
> All other files are checked into the repo root.
> Reason (and why it works fine with SVN):
> In ScmWagon.checkOut() targetName is split to existing parth an non-existing 
> part.
> in case of svn:
>  - checks out repoUrl + existingPart
>  - mkdirs missingPart
>  - return missingPart
> the caller copies the new file into coDir/ + missingPart/
> on second put() all dirs exist
>  - checks out repoUrl + allPart
>  - return empty string
> the caller copies the new file into coDir/
>  in case of cvs (on second put()):
>  - checks out repoUrl WITHOUT allPart
>  - returns empty string
>  the caller copies the new file into coDir/
> My current goal is to re-enable ScmCvsExeWagonTest. There are numerous bugs 
> in wagon-scm and fixing just one is not enough to run even a single test case.
> However, the proposed pull request will let you reach the point in 
> 

[jira] [Comment Edited] (MINSTALL-110) install-file should also install bundled pom.xml from artifact.

[dennis lucero (JIRA)]

[ 
https://issues.apache.org/jira/browse/MINSTALL-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16370034#comment-16370034
 ] 

dennis lucero edited comment on MINSTALL-110 at 2/20/18 1:14 PM:
-

It's 3 years after the bug has been fixed, and no release yet. It would help me 
(and I bet others) a bunch if we could cherry-pick this fix to a patch release.

Pretty please?

(EDIT: I would like to argue that this bug is not fixed if it's not being 
released, and so the issue should not be closed. From the POV of every customer 
for the past 3 years, this is still broken)


was (Author: striderapache):
It's 3 years after the bug has been fixed, and no release yet. It would help me 
(and I bet others) a bunch if we could cherry-pick this fix to a patch release.

Pretty please?

> install-file should also install bundled pom.xml from artifact.
> ---
>
> Key: MINSTALL-110
> URL: https://issues.apache.org/jira/browse/MINSTALL-110
> Project: Maven Install Plugin
>  Issue Type: Improvement
>  Components: install:install-file
>Affects Versions: 2.5.2
> Environment: Windows 7
>Reporter: Johan Ekesparr
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 3.0.0
>
> Attachments: test-1.0.0.jar
>
>
> Install:install-file uses the bundled pom.xml in the artifact-file to get the 
> *GAV* information for the artifact if no external pom.xml file is referenced.
> The install-file goal should also install the actual pom.xml file at the same 
> time. For some reason this is not happening in the current version.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MINSTALL-110) install-file should also install bundled pom.xml from artifact.

[dennis lucero (JIRA)]

[ 
https://issues.apache.org/jira/browse/MINSTALL-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16370034#comment-16370034
 ] 

dennis lucero commented on MINSTALL-110:


It's 3 years after the bug has been fixed, and no release yet. It would help me 
(and I bet others) a bunch if we could cherry-pick this fix to a patch release.

Pretty please?

> install-file should also install bundled pom.xml from artifact.
> ---
>
> Key: MINSTALL-110
> URL: https://issues.apache.org/jira/browse/MINSTALL-110
> Project: Maven Install Plugin
>  Issue Type: Improvement
>  Components: install:install-file
>Affects Versions: 2.5.2
> Environment: Windows 7
>Reporter: Johan Ekesparr
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 3.0.0
>
> Attachments: test-1.0.0.jar
>
>
> Install:install-file uses the bundled pom.xml in the artifact-file to get the 
> *GAV* information for the artifact if no external pom.xml file is referenced.
> The install-file goal should also install the actual pom.xml file at the same 
> time. For some reason this is not happening in the current version.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MASSEMBLY-877) give priority to module files when using jar-with-dependencies descriptor

[Simon (JIRA)]

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

Simon updated MASSEMBLY-877:

Description: 
Currently, when you create an uber jar using {{jar-with-dependencies}} 
descriptor if there is resource duplicates between current module and 
dependencies there is no guarantee the module one will be chosen.

E.g. :
 module A depends on module B.
 module A and module B contains a configuration file with the same name/ same 
path.

If I build A using jar-with-dependencies descriptor I have no guarantee my 
assembly will contains the configuration file of A.

I think this is because jar-with-dependencies use 
true and so there is no priority 
between the module and its dependencies.

A solution could be to change the descriptor and use something like this :
{code:xml}
http://maven.apache.org/ASSEMBLY/2.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/ASSEMBLY/2.0.0 
http://maven.apache.org/xsd/assembly-2.0.0.xsd;>
jar-with-dependencies

jar

false


${project.build.outputDirectory}
/




/
false
true
runtime



{code}
As FileSet have priority on dependencySet, it should do the tricks.

Does it make sense ?

  was:
Currently, when you create an uber jar using {{jar-with-dependencies}} 
descriptor if there is resource duplicates between current module and 
dependencies there is no guarantee the module one will be chosen.

E.g. :
 module A depends on module B.
 module A and module B contains a configuration file with the same name/ same 
path.

If I build A using jar-with-dependencies descriptor I have no guarantee my 
assembly will contains the configuration file of A.

I think this is because jar-with-dependencies use 
true and so there is no priority 
between the module and its dependencies.

A solution could be to change the descriptor and use something like this : 

{code:xml}
http://maven.apache.org/ASSEMBLY/2.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/ASSEMBLY/2.0.0 
http://maven.apache.org/xsd/assembly-2.0.0.xsd;>
jar-with-dependencies



jar

false


${project.build.outputDirectory}
/




/
false
true
runtime



{code}

As FileSet have priority on dependencySet, it should do the tricks.

Does it make sense ?



> give priority to module files when using jar-with-dependencies descriptor
> -
>
> Key: MASSEMBLY-877
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-877
> Project: Maven Assembly Plugin
>  Issue Type: Improvement
>  Components: component descriptor
>Reporter: Simon
>Priority: Major
>
> Currently, when you create an uber jar using {{jar-with-dependencies}} 
> descriptor if there is resource duplicates between current module and 
> dependencies there is no guarantee the module one will be chosen.
> E.g. :
>  module A depends on module B.
>  module A and module B contains a configuration file with the same name/ same 
> path.
> If I build A using jar-with-dependencies descriptor I have no guarantee my 
> assembly will contains the configuration file of A.
> I think this is because jar-with-dependencies use 
> true and so there is no priority 
> between the module and its dependencies.
> A solution could be to change the descriptor and use something like this :
> {code:xml}
> http://maven.apache.org/ASSEMBLY/2.0.0;
>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>   xsi:schemaLocation="http://maven.apache.org/ASSEMBLY/2.0.0 
> http://maven.apache.org/xsd/assembly-2.0.0.xsd;>
>   jar-with-dependencies
>   
>   jar
>   
>   false
>   
>   
>   ${project.build.outputDirectory}
>   /
>   
>   
>   
>   
>   /
>   false
>   true
>   runtime
>   
>   
> 
> {code}
> As FileSet have priority on dependencySet, it should do the tricks.
> Does it make sense ?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (SUREFIRE-1479) SurefireBooterForkException: The forked VM terminated without properly saying goodbye since 2.20.1

[Ondrej Lukas (JIRA)]

Ondrej Lukas created SUREFIRE-1479:
--

 Summary: SurefireBooterForkException: The forked VM terminated 
without properly saying goodbye since 2.20.1
 Key: SUREFIRE-1479
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1479
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Surefire Plugin
Affects Versions: 2.20.1
Reporter: Ondrej Lukas


After upgrade to maven surefire plugin to version 2.20.1 (from version 2.20) 
our testsuite start to fail on HP-UX with:
 
 
{code:java}
Process Exit Code: 1     at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.awaitResultsDone(ForkStarter.java:496)
     at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkPerTestSet(ForkStarter.java:443)
     at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:295)
     at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:246)
     at 
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1124)
     at 
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:954)
     at 
org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:832)
     at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
     at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) 
    at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154) 
    at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146) 
    at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
     at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
     at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
     at 
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
     at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)  
   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)     at 
org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)     at 
org.apache.maven.cli.MavenCli.execute(MavenCli.java:955)     at 
org.apache.maven.cli.MavenCli.doMain(MavenCli.java:290)     at 
org.apache.maven.cli.MavenCli.main(MavenCli.java:194)     at 
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)     at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)   
  at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
     at java.lang.reflect.Method.invoke(Method.java:498)     at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
     at 
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) 
    at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
     at 
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) 
Caused by: org.apache.maven.surefire.booter.SurefireBooterForkException: The 
forked VM terminated without properly saying goodbye. VM crash or System.exit 
called?{code}
 
 
This exception is thrown and no test cases are run.
 
I believe that this issue in not dependent on HP-UX since I found the same 
issue for windows [1], but it seems it has not been reported yet.
 
Since the only change between correct test execution and thrown exception is 
just change of surefire version I believe this is regression.
 
[1] 
[https://stackoverflow.com/questions/48631856/maven-surefire-forked-vm-terminated-issue-in-windows]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)