[jira] [Commented] (MCOMPILER-298) Support "-parameters" compiler option as a configuration key

2017-05-29 Thread Hudson (JIRA) 

[ 
https://issues.apache.org/jira/browse/MCOMPILER-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16028716#comment-16028716
 ] 

Hudson commented on MCOMPILER-298:
--

SUCCESS: Integrated in Jenkins build maven-plugins #8973 (See 
[https://builds.apache.org/job/maven-plugins/8973/])
[MCOMPILER-298] Add support for "parameters" flag
fixes #114 (olamy: [http://svn.apache.org/viewvc/?view=rev&rev=1796724])
* (edit) maven-compiler-plugin/pom.xml
* (add) maven-compiler-plugin/src/it/MCOMPILER-298
* (add) maven-compiler-plugin/src/it/MCOMPILER-298/invoker.properties
* (add) maven-compiler-plugin/src/it/MCOMPILER-298/pom.xml
* (add) maven-compiler-plugin/src/it/MCOMPILER-298/src
* (add) maven-compiler-plugin/src/it/MCOMPILER-298/src/main
* (add) maven-compiler-plugin/src/it/MCOMPILER-298/src/main/java
* (add) maven-compiler-plugin/src/it/MCOMPILER-298/src/main/java/com
* (add) maven-compiler-plugin/src/it/MCOMPILER-298/src/main/java/com/foo
* (add) 
maven-compiler-plugin/src/it/MCOMPILER-298/src/main/java/com/foo/ParameterClass.java
* (add) maven-compiler-plugin/src/it/MCOMPILER-298/src/test
* (add) maven-compiler-plugin/src/it/MCOMPILER-298/src/test/java
* (add) maven-compiler-plugin/src/it/MCOMPILER-298/src/test/java/com
* (add) maven-compiler-plugin/src/it/MCOMPILER-298/src/test/java/com/foo
* (add) 
maven-compiler-plugin/src/it/MCOMPILER-298/src/test/java/com/foo/ParameterTest.java
* (edit) 
maven-compiler-plugin/src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java


> Support "-parameters" compiler option as a configuration key
> 
>
> Key: MCOMPILER-298
> URL: https://issues.apache.org/jira/browse/MCOMPILER-298
> Project: Maven Compiler Plugin
>  Issue Type: Improvement
>Affects Versions: 3.6.1
>Reporter: brian clozel
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Minor
>  Labels: pull-request-available
> Fix For: 3.6.2
>
> Attachments: mcompiler298-IT.patch
>
>
> The {{-parameters}} flag is, as of JDK8, a standard compiler option for the 
> compiler. This option should be frequently used by developers and it would 
> make sense to have it as a first class option (like source, target and many 
> others) rather than using {{compilerArgs}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MCOMPILER-298) Support "-parameters" compiler option as a configuration key

2017-05-29 Thread *$^¨%`£ 

[ 
https://issues.apache.org/jira/browse/MCOMPILER-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16028711#comment-16028711
 ] 

Olivier Lamy (*$^¨%`£) commented on MCOMPILER-298:
--

pr merged.
IT applied as well with changes.
https://svn.apache.org/r1796724

> Support "-parameters" compiler option as a configuration key
> 
>
> Key: MCOMPILER-298
> URL: https://issues.apache.org/jira/browse/MCOMPILER-298
> Project: Maven Compiler Plugin
>  Issue Type: Improvement
>Affects Versions: 3.6.1
>Reporter: brian clozel
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Minor
>  Labels: pull-request-available
> Fix For: 3.6.2
>
> Attachments: mcompiler298-IT.patch
>
>
> The {{-parameters}} flag is, as of JDK8, a standard compiler option for the 
> compiler. This option should be frequently used by developers and it would 
> make sense to have it as a first class option (like source, target and many 
> others) rather than using {{compilerArgs}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MANTRUN-181) AttachArtifact task does not work in external Ant build file

2017-05-29 Thread Hudson (JIRA) 

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

Hudson commented on MANTRUN-181:


SUCCESS: Integrated in Jenkins build maven-plugins #8972 (See 
[https://builds.apache.org/job/maven-plugins/8972/])
[MANTRUN-181] AttachArtifact task does not work in external Ant build file

Instead of overriding the Ant project and forcing to pass the Ant project 
references by reference to sub-projects, it is cleaner to add in the plugin 
another reference, containing the Maven project, that cannot be cloned. This 
way, a task that wants to change the Maven project can obtain this new 
reference (like 'attachartifact'), and old code behaves exactly like before. It 
is important that this new reference is not clonable, so that inheritRefs=true 
doesn't pass a clone of it to an external Ant build called with the 'ant' task, 
but the reference itself. (gboue: 
[http://svn.apache.org/viewvc/?view=rev&rev=1796719])
* (edit) maven-antrun-plugin/src/it/attach-artifact-from-ant-task/pom.xml
* (edit) 
maven-antrun-plugin/src/main/java/org/apache/maven/ant/tasks/AttachArtifactTask.java
* (edit) 
maven-antrun-plugin/src/main/java/org/apache/maven/plugin/antrun/AntRunMojo.java
* (edit) 
maven-antrun-plugin/src/main/java/org/apache/maven/plugin/antrun/MavenAntRunProject.java


> AttachArtifact task does not work in external Ant build file
> 
>
> Key: MANTRUN-181
> URL: https://issues.apache.org/jira/browse/MANTRUN-181
> Project: Maven Antrun Plugin
>  Issue Type: Bug
>Affects Versions: 1.5, 1.6, 1.7
>Reporter: Anton Khitrenovich
> Attachments: MyProject.zip
>
>
> AttachArtifact task fails with an error if used in external Ant build file:
> {code}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-antrun-plugin:1.7:run (call-build) on project 
> my-test-project: An Ant BuildException has occured: The following error 
> occurred while executing this line:
> [ERROR] C:\...\MyProject\build.xml:5: Maven project reference not found: 
> maven.project
> [ERROR] around Ant part .. @ 
> 4:47 in C:\...\MyProject\target\antrun\build-main.xml
> {code}
> Setting {{inheritRefs="true"}} eliminates the error, but even then the 
> artifact is not attached.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MANTRUN-181) AttachArtifact task does not work in external Ant build file

2017-05-29 Thread JIRA 

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

Guillaume Boué commented on MANTRUN-181:


Follow-up in [r1796719|http://svn.apache.org/viewvc?rev=1796719&view=rev], with 
an improved solution. Note that {{inheritRefs="true"}} has to be set in the 
{{ant}} call for this to work.

> AttachArtifact task does not work in external Ant build file
> 
>
> Key: MANTRUN-181
> URL: https://issues.apache.org/jira/browse/MANTRUN-181
> Project: Maven Antrun Plugin
>  Issue Type: Bug
>Affects Versions: 1.5, 1.6, 1.7
>Reporter: Anton Khitrenovich
> Attachments: MyProject.zip
>
>
> AttachArtifact task fails with an error if used in external Ant build file:
> {code}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-antrun-plugin:1.7:run (call-build) on project 
> my-test-project: An Ant BuildException has occured: The following error 
> occurred while executing this line:
> [ERROR] C:\...\MyProject\build.xml:5: Maven project reference not found: 
> maven.project
> [ERROR] around Ant part .. @ 
> 4:47 in C:\...\MyProject\target\antrun\build-main.xml
> {code}
> Setting {{inheritRefs="true"}} eliminates the error, but even then the 
> artifact is not attached.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

2017-05-29 Thread JIRA 

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

Guillaume Boué commented on SUREFIRE-1376:
--

It's {{260 - 12 - 1}}. The 12 comes from the fact that the new method could be 
called on a directory, in which case MSDN specifies that "the specified path 
cannot be so long that you cannot append an 8.3 file name (that is, the 
directory name cannot exceed MAX_PATH minus 12)." This is actually what OpenJDK 
is doing behind the scenes as well in 
[{{WindowsPath}}|http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/7534523b4174/src/windows/classes/sun/nio/fs/WindowsPath.java#l46].

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



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MNG-6220) Add CLI options to control color output

2017-05-29 Thread Cyrille Le Clerc (JIRA) 

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

Cyrille Le Clerc commented on MNG-6220:
---

The [Jenkins Pipeline Maven 
Plugin|https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Maven+Plugin] would 
be very interested in having the colored output enable when the batch mode is 
enabled.
We run Maven builds in batch mode to be not interactive but we would like to 
benefit of the colorized output.

Reference https://issues.jenkins-ci.org/browse/JENKINS-44543

> Add CLI options to control color output
> ---
>
> Key: MNG-6220
> URL: https://issues.apache.org/jira/browse/MNG-6220
> Project: Maven
>  Issue Type: New Feature
>Reporter: Manuel Ryan
> Fix For: 3.5.1-candidate
>
>
> Currently, the only way to enable/disable color output is to use the 
> batch-mode or log-file options.
> If a user wants colored output but no interactivity (ie: jenkins environment 
> with the ansicolor plugin), there is no CLI option combination to support the 
> use-case.
> I propose to add an option to control output coloring directly.
> {noformat}
> --color=enabled <- color output always enabled
> --color=disabled <- color output always disabled
> --color=auto <- current behavior (default)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

2017-05-29 Thread Tibor Digana (JIRA) 

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

Tibor Digana commented on SUREFIRE-1376:


[~gboue]
How did you compute 247?
In the MSDN you sent me {{"D:\some 256-character path string"}} 
MAX_PATH_LENGTH_WINDOWS can be 259.
Basically it does not much matter because the number are very similar and 
prefix {{"?\\"}} does not harm the path.

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



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

2017-05-29 Thread Tibor Digana (JIRA) 

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

Tibor Digana updated SUREFIRE-1376:
---
Fix Version/s: 2.20.1

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



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

2017-05-29 Thread Tibor Digana (JIRA) 

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

Tibor Digana reassigned SUREFIRE-1376:
--

Assignee: Tibor Digana

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



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MANTRUN-181) AttachArtifact task does not work in external Ant build file

2017-05-29 Thread Hudson (JIRA) 

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

Hudson commented on MANTRUN-181:


SUCCESS: Integrated in Jenkins build maven-plugins #8971 (See 
[https://builds.apache.org/job/maven-plugins/8971/])
[MANTRUN-181] AttachArtifact task does not work in external Ant build file

When the run goal executes an Ant task that calls an external Ant build file, 
Ant creates a sub-project of the main Ant project that was created for the 
(parent) Ant task. However, the project's references are not passed to the 
sub-project, meaning that whatever Maven added as a reference to the main 
project is lost when calling the external build file. This notably includes the 
"maven.project" and "maven.project.helper" references that are needed for the 
'attachartifact' built-in task to work.

This is resolved by overriding the way of creating sub-projects, so that 
references added to an Ant project by Maven are passed to any sub-projects. 
(gboue: [http://svn.apache.org/viewvc/?view=rev&rev=1796671])
* (add) maven-antrun-plugin/src/it/attach-artifact-from-ant-task
* (add) maven-antrun-plugin/src/it/attach-artifact-from-ant-task/build.xml
* (add) 
maven-antrun-plugin/src/it/attach-artifact-from-ant-task/invoker.properties
* (add) maven-antrun-plugin/src/it/attach-artifact-from-ant-task/pom.xml
* (add) maven-antrun-plugin/src/it/attach-artifact-from-ant-task/test.txt
* (add) maven-antrun-plugin/src/it/attach-artifact-from-ant-task/verify.bsh
* (edit) 
maven-antrun-plugin/src/main/java/org/apache/maven/plugin/antrun/AntRunMojo.java
* (add) 
maven-antrun-plugin/src/main/java/org/apache/maven/plugin/antrun/MavenAntRunProject.java


> AttachArtifact task does not work in external Ant build file
> 
>
> Key: MANTRUN-181
> URL: https://issues.apache.org/jira/browse/MANTRUN-181
> Project: Maven Antrun Plugin
>  Issue Type: Bug
>Affects Versions: 1.5, 1.6, 1.7
>Reporter: Anton Khitrenovich
> Attachments: MyProject.zip
>
>
> AttachArtifact task fails with an error if used in external Ant build file:
> {code}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-antrun-plugin:1.7:run (call-build) on project 
> my-test-project: An Ant BuildException has occured: The following error 
> occurred while executing this line:
> [ERROR] C:\...\MyProject\build.xml:5: Maven project reference not found: 
> maven.project
> [ERROR] around Ant part .. @ 
> 4:47 in C:\...\MyProject\target\antrun\build-main.xml
> {code}
> Setting {{inheritRefs="true"}} eliminates the error, but even then the 
> artifact is not attached.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MANTRUN-181) AttachArtifact task does not work in external Ant build file

2017-05-29 Thread JIRA 

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

Guillaume Boué commented on MANTRUN-181:


Fixed in [r1796671|http://svn.apache.org/viewvc?rev=1796671&view=rev].

> AttachArtifact task does not work in external Ant build file
> 
>
> Key: MANTRUN-181
> URL: https://issues.apache.org/jira/browse/MANTRUN-181
> Project: Maven Antrun Plugin
>  Issue Type: Bug
>Affects Versions: 1.5, 1.6, 1.7
>Reporter: Anton Khitrenovich
> Attachments: MyProject.zip
>
>
> AttachArtifact task fails with an error if used in external Ant build file:
> {code}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-antrun-plugin:1.7:run (call-build) on project 
> my-test-project: An Ant BuildException has occured: The following error 
> occurred while executing this line:
> [ERROR] C:\...\MyProject\build.xml:5: Maven project reference not found: 
> maven.project
> [ERROR] around Ant part .. @ 
> 4:47 in C:\...\MyProject\target\antrun\build-main.xml
> {code}
> Setting {{inheritRefs="true"}} eliminates the error, but even then the 
> artifact is not attached.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (MCOMPILER-298) Support "-parameters" compiler option as a configuration key

2017-05-29 Thread Robert Scholte (JIRA) 

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

Robert Scholte updated MCOMPILER-298:
-
Attachment: mcompiler298-IT.patch

I think this patch contains an IT which should work.

> Support "-parameters" compiler option as a configuration key
> 
>
> Key: MCOMPILER-298
> URL: https://issues.apache.org/jira/browse/MCOMPILER-298
> Project: Maven Compiler Plugin
>  Issue Type: Improvement
>Affects Versions: 3.6.1
>Reporter: brian clozel
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Minor
>  Labels: pull-request-available
> Fix For: 3.6.2
>
> Attachments: mcompiler298-IT.patch
>
>
> The {{-parameters}} flag is, as of JDK8, a standard compiler option for the 
> compiler. This option should be frequently used by developers and it would 
> make sense to have it as a first class option (like source, target and many 
> others) rather than using {{compilerArgs}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SUREFIRE-1374) std/in stream corrupted error

2017-05-29 Thread matteo rulli (JIRA) 

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

matteo rulli commented on SUREFIRE-1374:


Thank you Tibor for your help on this. The jvm is Java HotSpot(TM) 64-Bit 
Server VM (build 25.74-b02, mixed mode).

I'm going to follow your suggestions and I'll post here the results.

> std/in stream corrupted error
> -
>
> Key: SUREFIRE-1374
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1374
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: matteo rulli
>Assignee: Tibor Digana
>
> We bumbed surefire version to 2.20 (from 2.19.1) and our tests started 
> generating this kind of errors:
> {code}
> # Created on 2017-05-26T10:24:04.032
> [SUREFIRE] std/in stream corrupted
> java.io.IOException: Command BYE_ACK unexpectedly read Void data with length 
> 4.
>   at 
> org.apache.maven.surefire.booter.MasterProcessCommand.decode(MasterProcessCommand.java:130)
>   at 
> org.apache.maven.surefire.booter.CommandReader$CommandRunnable.run(CommandReader.java:386)
>   at java.lang.Thread.run(Thread.java:745)
> {code}
> Related stacktrace:
> {code}
> [ERROR] Error occurred in starting fork, check output in log
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: Error 
> occurred in starting fork, check output in log
> [ERROR]   at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:634)
> [ERROR]   at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:533)
> [ERROR]   at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:279)
> [ERROR]   at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:243)
> [ERROR]   at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1077)
> [ERROR]   at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:907)
> [ERROR]   at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:785)
> [ERROR]   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> [ERROR]   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> [ERROR]   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> [ERROR]   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> [ERROR]   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> [ERROR]   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> [ERROR]   at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> [ERROR]   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> [ERROR]   at 
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
> [ERROR]   at 
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
> [ERROR]   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
> [ERROR]   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
> [ERROR]   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
> [ERROR]   at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
> [ERROR]   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [ERROR]   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [ERROR]   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [ERROR]   at java.lang.reflect.Method.invoke(Method.java:498)
> [ERROR]   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> [ERROR]   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> [ERROR]   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> [ERROR]   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> [
> {code}
> Everything worked fine with 2.19.1.
> Environment: macOS sierra, java version "1.8.0_74", Apache Maven 3.5.0  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

2017-05-29 Thread Michael Osipov (JIRA) 

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

Michael Osipov updated MASSEMBLY-854:
-
Summary: Upgrade to Plexus Archiver 3.5  (was: Upgrade to plexus archiver 
3.5)

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



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MASSEMBLY-854) Upgrade to plexus archiver 3.5

2017-05-29 Thread Stephane Nicoll (JIRA) 
Stephane Nicoll created MASSEMBLY-854:
-

 Summary: Upgrade to plexus archiver 3.5
 Key: MASSEMBLY-854
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-854
 Project: Maven Assembly Plugin
  Issue Type: Task
Affects Versions: 3.0.0
Reporter: Stephane Nicoll
 Fix For: 3.0.1


There is a critical regression fixed (see 
https://github.com/codehaus-plexus/plexus-archiver/issues/53)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (MCOMPILER-298) Support "-parameters" compiler option as a configuration key

2017-05-29 Thread *$^¨%`£ 

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

Olivier Lamy (*$^¨%`£) updated MCOMPILER-298:
-
Fix Version/s: 3.6.2

> Support "-parameters" compiler option as a configuration key
> 
>
> Key: MCOMPILER-298
> URL: https://issues.apache.org/jira/browse/MCOMPILER-298
> Project: Maven Compiler Plugin
>  Issue Type: Improvement
>Affects Versions: 3.6.1
>Reporter: brian clozel
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Minor
>  Labels: pull-request-available
> Fix For: 3.6.2
>
>
> The {{-parameters}} flag is, as of JDK8, a standard compiler option for the 
> compiler. This option should be frequently used by developers and it would 
> make sense to have it as a first class option (like source, target and many 
> others) rather than using {{compilerArgs}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (MCOMPILER-298) Support "-parameters" compiler option as a configuration key

2017-05-29 Thread *$^¨%`£ 

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

Olivier Lamy (*$^¨%`£) reassigned MCOMPILER-298:


Assignee: Olivier Lamy (*$^¨%`£)

> Support "-parameters" compiler option as a configuration key
> 
>
> Key: MCOMPILER-298
> URL: https://issues.apache.org/jira/browse/MCOMPILER-298
> Project: Maven Compiler Plugin
>  Issue Type: Improvement
>Affects Versions: 3.6.1
>Reporter: brian clozel
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Minor
>  Labels: pull-request-available
>
> The {{-parameters}} flag is, as of JDK8, a standard compiler option for the 
> compiler. This option should be frequently used by developers and it would 
> make sense to have it as a first class option (like source, target and many 
> others) rather than using {{compilerArgs}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MRESOLVER-25) Resume support is broken under high concurrency

2017-05-29 Thread Michael Osipov (JIRA) 

[ 
https://issues.apache.org/jira/browse/MRESOLVER-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16028231#comment-16028231
 ] 

Michael Osipov commented on MRESOLVER-25:
-

This is another bug, locking for the {{lastUpdated}} file.

> Resume support is broken under high concurrency
> ---
>
> Key: MRESOLVER-25
> URL: https://issues.apache.org/jira/browse/MRESOLVER-25
> Project: Maven Resolver
>  Issue Type: Bug
>  Components: resolver
>Affects Versions: Maven Artifact Resolver 1.0.3
>Reporter: Roland Illig
> Attachments: dependency-list.txt, dependency-list-x.zip, 
> wagon-not-threadsafe.zip
>
>
> When building a multi-module project in parallel, Maven updates the local 
> Maven repository without taking into account that other threads or processes 
> might do the same at the same time.
> To reproduce:
> 1.  unpack the attached project
> 2.  {{mvn dependency:list -U -B -T100}}
> See the attached {{dependency-list.txt}} for an example output.
> First thing to notice is that the dependency is downloaded 100 times. This is 
> unexpected, since the Reactor should coordinate all the modules.
> Second thing to notice is that the build fails, since a dependency "cannot be 
> found". This is wrong, since the dependency _can_ be found, it's just not 
> processed properly.
> I suspect the {{legacy.DefaultWagonManager}} to be the cause of this, since 
> the typical error messages are:
> * {{"Downloaded file does not exist: "}}
> * {{"Error copying temporary file to the final destination: "}}
> * {{"*** CHECKSUM FAILED - RETRYING"}}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (MCOMPILER-298) Support "-parameters" compiler option as a configuration key

2017-05-29 Thread Stephane Nicoll (JIRA) 

[ 
https://issues.apache.org/jira/browse/MCOMPILER-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16028223#comment-16028223
 ] 

Stephane Nicoll edited comment on MCOMPILER-298 at 5/29/17 10:58 AM:
-

There is a change required in plexus compiler to make that happen, see PR
https://github.com/codehaus-plexus/plexus-compiler/pull/29

There is a PR available that needs a review: 
https://github.com/apache/maven-plugins/pull/114 (in particular I have no idea 
how to test the flag in an IT)


was (Author: snicoll):
There is a change required in plexus compiler to make that happen, see PR
https://github.com/codehaus-plexus/plexus-compiler/pull/29

There is a PR available that needs a review: 
https://github.com/apache/maven-plugins/pull/114

> Support "-parameters" compiler option as a configuration key
> 
>
> Key: MCOMPILER-298
> URL: https://issues.apache.org/jira/browse/MCOMPILER-298
> Project: Maven Compiler Plugin
>  Issue Type: Improvement
>Affects Versions: 3.6.1
>Reporter: brian clozel
>Priority: Minor
>  Labels: pull-request-available
>
> The {{-parameters}} flag is, as of JDK8, a standard compiler option for the 
> compiler. This option should be frequently used by developers and it would 
> make sense to have it as a first class option (like source, target and many 
> others) rather than using {{compilerArgs}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (MCOMPILER-298) Support "-parameters" compiler option as a configuration key

2017-05-29 Thread Stephane Nicoll (JIRA) 

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

Stephane Nicoll updated MCOMPILER-298:
--
Affects Version/s: 3.6.1
   Labels: pull-request-available  (was: )

> Support "-parameters" compiler option as a configuration key
> 
>
> Key: MCOMPILER-298
> URL: https://issues.apache.org/jira/browse/MCOMPILER-298
> Project: Maven Compiler Plugin
>  Issue Type: Improvement
>Affects Versions: 3.6.1
>Reporter: brian clozel
>Priority: Minor
>  Labels: pull-request-available
>
> The {{-parameters}} flag is, as of JDK8, a standard compiler option for the 
> compiler. This option should be frequently used by developers and it would 
> make sense to have it as a first class option (like source, target and many 
> others) rather than using {{compilerArgs}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (MCOMPILER-298) Support "-parameters" compiler option as a configuration key

2017-05-29 Thread Stephane Nicoll (JIRA) 

[ 
https://issues.apache.org/jira/browse/MCOMPILER-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16028223#comment-16028223
 ] 

Stephane Nicoll edited comment on MCOMPILER-298 at 5/29/17 10:57 AM:
-

There is a change required in plexus compiler to make that happen, see PR
https://github.com/codehaus-plexus/plexus-compiler/pull/29

There is a PR available that needs a review: 
https://github.com/apache/maven-plugins/pull/114


was (Author: snicoll):
There is a change required in plexus compiler to make that happen, see PR
https://github.com/codehaus-plexus/plexus-compiler/pull/29

> Support "-parameters" compiler option as a configuration key
> 
>
> Key: MCOMPILER-298
> URL: https://issues.apache.org/jira/browse/MCOMPILER-298
> Project: Maven Compiler Plugin
>  Issue Type: Improvement
>Affects Versions: 3.6.1
>Reporter: brian clozel
>Priority: Minor
>  Labels: pull-request-available
>
> The {{-parameters}} flag is, as of JDK8, a standard compiler option for the 
> compiler. This option should be frequently used by developers and it would 
> make sense to have it as a first class option (like source, target and many 
> others) rather than using {{compilerArgs}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MCOMPILER-298) Support "-parameters" compiler option as a configuration key

2017-05-29 Thread Stephane Nicoll (JIRA) 

[ 
https://issues.apache.org/jira/browse/MCOMPILER-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16028223#comment-16028223
 ] 

Stephane Nicoll commented on MCOMPILER-298:
---

There is a change required in plexus compiler to make that happen, see PR
https://github.com/codehaus-plexus/plexus-compiler/pull/29

> Support "-parameters" compiler option as a configuration key
> 
>
> Key: MCOMPILER-298
> URL: https://issues.apache.org/jira/browse/MCOMPILER-298
> Project: Maven Compiler Plugin
>  Issue Type: Improvement
>Reporter: brian clozel
>Priority: Minor
>
> The {{-parameters}} flag is, as of JDK8, a standard compiler option for the 
> compiler. This option should be frequently used by developers and it would 
> make sense to have it as a first class option (like source, target and many 
> others) rather than using {{compilerArgs}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MCOMPILER-298) Support "-parameters" compiler option as a configuration key

2017-05-29 Thread brian clozel (JIRA) 
brian clozel created MCOMPILER-298:
--

 Summary: Support "-parameters" compiler option as a configuration 
key
 Key: MCOMPILER-298
 URL: https://issues.apache.org/jira/browse/MCOMPILER-298
 Project: Maven Compiler Plugin
  Issue Type: Improvement
Reporter: brian clozel
Priority: Minor


The {{-parameters}} flag is, as of JDK8, a standard compiler option for the 
compiler. This option should be frequently used by developers and it would make 
sense to have it as a first class option (like source, target and many others) 
rather than using {{compilerArgs}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MRESOLVER-25) Resume support is broken under high concurrency

2017-05-29 Thread Roland Illig (JIRA) 

[ 
https://issues.apache.org/jira/browse/MRESOLVER-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16028146#comment-16028146
 ] 

Roland Illig commented on MRESOLVER-25:
---

Yes, exactly that.

> Resume support is broken under high concurrency
> ---
>
> Key: MRESOLVER-25
> URL: https://issues.apache.org/jira/browse/MRESOLVER-25
> Project: Maven Resolver
>  Issue Type: Bug
>  Components: resolver
>Affects Versions: Maven Artifact Resolver 1.0.3
>Reporter: Roland Illig
> Attachments: dependency-list.txt, dependency-list-x.zip, 
> wagon-not-threadsafe.zip
>
>
> When building a multi-module project in parallel, Maven updates the local 
> Maven repository without taking into account that other threads or processes 
> might do the same at the same time.
> To reproduce:
> 1.  unpack the attached project
> 2.  {{mvn dependency:list -U -B -T100}}
> See the attached {{dependency-list.txt}} for an example output.
> First thing to notice is that the dependency is downloaded 100 times. This is 
> unexpected, since the Reactor should coordinate all the modules.
> Second thing to notice is that the build fails, since a dependency "cannot be 
> found". This is wrong, since the dependency _can_ be found, it's just not 
> processed properly.
> I suspect the {{legacy.DefaultWagonManager}} to be the cause of this, since 
> the typical error messages are:
> * {{"Downloaded file does not exist: "}}
> * {{"Error copying temporary file to the final destination: "}}
> * {{"*** CHECKSUM FAILED - RETRYING"}}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MRESOLVER-25) Resume support is broken under high concurrency

2017-05-29 Thread Michael Osipov (JIRA) 

[ 
https://issues.apache.org/jira/browse/MRESOLVER-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16028140#comment-16028140
 ] 

Michael Osipov commented on MRESOLVER-25:
-

Did you receive the exception even with the resume support disabled?

> Resume support is broken under high concurrency
> ---
>
> Key: MRESOLVER-25
> URL: https://issues.apache.org/jira/browse/MRESOLVER-25
> Project: Maven Resolver
>  Issue Type: Bug
>  Components: resolver
>Affects Versions: Maven Artifact Resolver 1.0.3
>Reporter: Roland Illig
> Attachments: dependency-list.txt, dependency-list-x.zip, 
> wagon-not-threadsafe.zip
>
>
> When building a multi-module project in parallel, Maven updates the local 
> Maven repository without taking into account that other threads or processes 
> might do the same at the same time.
> To reproduce:
> 1.  unpack the attached project
> 2.  {{mvn dependency:list -U -B -T100}}
> See the attached {{dependency-list.txt}} for an example output.
> First thing to notice is that the dependency is downloaded 100 times. This is 
> unexpected, since the Reactor should coordinate all the modules.
> Second thing to notice is that the build fails, since a dependency "cannot be 
> found". This is wrong, since the dependency _can_ be found, it's just not 
> processed properly.
> I suspect the {{legacy.DefaultWagonManager}} to be the cause of this, since 
> the typical error messages are:
> * {{"Downloaded file does not exist: "}}
> * {{"Error copying temporary file to the final destination: "}}
> * {{"*** CHECKSUM FAILED - RETRYING"}}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MRESOLVER-25) Resume support is broken under high concurrency

2017-05-29 Thread Roland Illig (JIRA) 

[ 
https://issues.apache.org/jira/browse/MRESOLVER-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16028108#comment-16028108
 ] 

Roland Illig commented on MRESOLVER-25:
---

Yes, the workaround works for me. Thank you.

The files were downloaded correctly and I got a {{BUILD SUCCESS}}, I just got 
the following exception about 7 times, for several of the involved artifacts:

{noformat}
[WARNING] Failed to write tracking file 
C:\Users\rillig\.m2\repository\org\webjars\bower\datatables.net-buttons\1.2.4\datatables.net-buttons-1.2.4.pom.lastUpdated
java.io.FileNotFoundException: 
C:\Users\rillig\.m2\repository\org\webjars\bower\datatables.net-buttons\1.2.4\datatables.net-buttons-1.2.4.pom.lastUpdated
 (Zugriff verweigert)
at java.io.RandomAccessFile.open0(Native Method)
at java.io.RandomAccessFile.open(RandomAccessFile.java:316)
at java.io.RandomAccessFile.(RandomAccessFile.java:243)
at 
org.eclipse.aether.internal.impl.TrackingFileManager.update(TrackingFileManager.java:96)
at 
org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write(DefaultUpdateCheckManager.java:602)
at 
org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact(DefaultUpdateCheckManager.java:538)
at 
org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads(DefaultArtifactResolver.java:631)
at 
org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:550)
at 
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:436)
at 
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:262)
at 
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:239)
{noformat}

> Resume support is broken under high concurrency
> ---
>
> Key: MRESOLVER-25
> URL: https://issues.apache.org/jira/browse/MRESOLVER-25
> Project: Maven Resolver
>  Issue Type: Bug
>  Components: resolver
>Affects Versions: Maven Artifact Resolver 1.0.3
>Reporter: Roland Illig
> Attachments: dependency-list.txt, dependency-list-x.zip, 
> wagon-not-threadsafe.zip
>
>
> When building a multi-module project in parallel, Maven updates the local 
> Maven repository without taking into account that other threads or processes 
> might do the same at the same time.
> To reproduce:
> 1.  unpack the attached project
> 2.  {{mvn dependency:list -U -B -T100}}
> See the attached {{dependency-list.txt}} for an example output.
> First thing to notice is that the dependency is downloaded 100 times. This is 
> unexpected, since the Reactor should coordinate all the modules.
> Second thing to notice is that the build fails, since a dependency "cannot be 
> found". This is wrong, since the dependency _can_ be found, it's just not 
> processed properly.
> I suspect the {{legacy.DefaultWagonManager}} to be the cause of this, since 
> the typical error messages are:
> * {{"Downloaded file does not exist: "}}
> * {{"Error copying temporary file to the final destination: "}}
> * {{"*** CHECKSUM FAILED - RETRYING"}}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)