[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&focusedCommentId=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
[ https://issues.apache.org/jira/browse/SUREFIRE-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/MINSTALL-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/MINSTALL-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&focusedCommentId=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 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
[ 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
[ https://issues.apache.org/jira/browse/MPH-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/MPH-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/MARCHETYPES-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&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
[ https://issues.apache.org/jira/browse/MNG-6215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ https://issues.apache.org/jira/browse/MPOM-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ 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
[ 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
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.
[ https://issues.apache.org/jira/browse/MANTRUN-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.
[ 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
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
[ 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&s=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
[ https://issues.apache.org/jira/browse/SUREFIRE-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/SUREFIRE-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/MPH-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ https://issues.apache.org/jira/browse/MPH-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ 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
[ 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
[ 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
[ https://issues.apache.org/jira/browse/MNG-6323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
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
[ https://issues.apache.org/jira/browse/MASSEMBLY-675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ https://issues.apache.org/jira/browse/MASSEMBLY-675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/MASSEMBLY-675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 configSour
[GitHub] asfgit closed pull request #2: [MASSEMBLY-675] Require maven to solve dependencies instead of buildi?
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, result, dependencySet, in
[jira] [Updated] (MASSEMBLY-877) give priority to module files when using jar-with-dependencies descriptor
[ 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
[ 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 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 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
[ 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 > [WagonTestCase#testWagonGetFileList()|https://github.com/apache/maven-wagon/blob/be94400731575f54ff537ec90359460f42a561cc/wagon-provider-test/src/main/jav
[jira] [Comment Edited] (MINSTALL-110) install-file should also install bundled pom.xml from artifact.
[ https://issues.apache.org/jira/browse/MINSTALL-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.
[ https://issues.apache.org/jira/browse/MINSTALL-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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 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)