[jira] [Commented] (MDEP-518) Dependency resolution fails in threaded builds

[James B (JIRA)]

[ 
https://issues.apache.org/jira/browse/MDEP-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16684863#comment-16684863
 ] 

James B commented on MDEP-518:
--

I am also experiencing this issue. I'm using maven 3.5.0 but see no need to try 
on latest, as the previous comment shows 3.5.4 still broken.

I have a very large multi-module project with hundreds of modules and a complex 
reactor graph, thus lending itself very well to parallel building. With 
single-process build it works fine, with -T1.5C it fails fairly early on with 
something like:

 
{code:java}
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-surefire-plugin:2.22.1:test (default-test) on 
project XXX: Unable to generate classpath: 
org.apache.maven.artifact.resolver.ArtifactResolutionException: Unable to get 
dependency information for 
org.apache.maven.surefire:surefire-junit-platform:jar:2.22.1: Failed to 
retrieve POM for org.apache.maven.surefire:surefire-junit-platform:jar:2.22.1: 
Could not transfer artifact 
org.apache.maven.surefire:surefire-junit-platform:pom:2.22.1 from/to REPO 
(https://repo.lan/artifactory/maven/maven2): 
/build/workspace/JOB/.repository/org/apache/maven/surefire/surefire-junit-platform/2.22.1/surefire-junit-platform-2.22.1.pom.part
 (No such file or directory)
[ERROR]   org.apache.maven.surefire:surefire-junit-platform:jar:2.22.1
{code}
 

Note again that the file not being found is the ".part".

At first glance this appears to happen when two threads simultaneously download 
the same artifact. As surefire itself is failing, maybe this is specific to 
plugin dependency resolution? The original reported exception indicates the 
problem also happens on standard artifacts.

Appears related to a recently revived issue, with a new Pull Request: 
[MNG-2802|https://issues.apache.org/jira/browse/MNG-2802?focusedCommentId=16584418=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16584418]

 

 

> Dependency resolution fails in threaded builds
> --
>
> Key: MDEP-518
> URL: https://issues.apache.org/jira/browse/MDEP-518
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: resolve, resolve-plugins
>Affects Versions: 2.10
> Environment: Linux
>Reporter: Troy Telford
>Priority: Major
>
> This issue sounds similar to MDEP-442, but it may be unrelated.
> I suspect the same problem may occur in both {{dependency:resolve}} and 
> {{dependency:resolve-plugins}}.
> The same error occurs when I use {{mvn install}}; but {{dependency:resolve}} 
> is a more tightly-focused problem report.
> I have a large multi-module project, with more than 40 modules, and a 
> large-ish build node with 24 cores.  {{mvn -T1C dependency:resolve 
> dependency:resolve-plugins}} will typically (94/100 attempts) fail to 
> download all of the dependencies required, with an error similar to:
> {noformat}
> Failed to read artifact descriptor for com.foo:machine:jar:1.2.3-SNAPSHOT: 
> Could not transfer artifact com.foo.somegroup:dependency_4:jar:3.0.0 from/to 
> snapshot-repository (https://nexus.foo.com/content/repositories/releases): 
> /home/userid/.m2/repository/com/foo/somegroup/dependency_4/3.0.0/dependency_4-3.0.0.pom.part
>  (No such file or directory) -> [Help 1]
> -> com.foo.somegroup:dependency_4:jar:3.0.0
> at 
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:220)
> at 
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:127)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:257)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:200)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at 
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:188)
> at 
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:184)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at 
> 

[jira] [Commented] (MDEP-518) Dependency resolution fails in threaded builds

[James B (JIRA)]

[ 
https://issues.apache.org/jira/browse/MDEP-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16684909#comment-16684909
 ] 

James B commented on MDEP-518:
--

Confirmed fixed by using Takari's builder, which provides a thread-safe 
implementation of the maven local repo.

[http://takari.io/book/30-team-maven.html#concurrent-safe-local-repository]

Simply place takari-smart-builder-VERSION.jar in your $MAVEN_HOME/lib/ext and 
invoke maven with "--builder smart" option.

> Dependency resolution fails in threaded builds
> --
>
> Key: MDEP-518
> URL: https://issues.apache.org/jira/browse/MDEP-518
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: resolve, resolve-plugins
>Affects Versions: 2.10
> Environment: Linux
>Reporter: Troy Telford
>Priority: Major
>
> This issue sounds similar to MDEP-442, but it may be unrelated.
> I suspect the same problem may occur in both {{dependency:resolve}} and 
> {{dependency:resolve-plugins}}.
> The same error occurs when I use {{mvn install}}; but {{dependency:resolve}} 
> is a more tightly-focused problem report.
> I have a large multi-module project, with more than 40 modules, and a 
> large-ish build node with 24 cores.  {{mvn -T1C dependency:resolve 
> dependency:resolve-plugins}} will typically (94/100 attempts) fail to 
> download all of the dependencies required, with an error similar to:
> {noformat}
> Failed to read artifact descriptor for com.foo:machine:jar:1.2.3-SNAPSHOT: 
> Could not transfer artifact com.foo.somegroup:dependency_4:jar:3.0.0 from/to 
> snapshot-repository (https://nexus.foo.com/content/repositories/releases): 
> /home/userid/.m2/repository/com/foo/somegroup/dependency_4/3.0.0/dependency_4-3.0.0.pom.part
>  (No such file or directory) -> [Help 1]
> -> com.foo.somegroup:dependency_4:jar:3.0.0
> at 
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:220)
> at 
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:127)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:257)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:200)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at 
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:188)
> at 
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:184)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: org.apache.maven.project.DependencyResolutionException: Could not 
> resolve dependencies for project com.foo:machine:jar:1.2.3-SNAPSHOT: Failed 
> to collect dependencies at com.foo:dependency_1:jar:1.2.3-SNAPSHOT -> 
> com.foo:dependency_2:jar:1.2.3-SNAPSHOT -> 
> com.foo:dependency_3:jar:1.2.3-SNAPSHOT -> 
> com.foo.somegroup:dependency_4:jar:3.0.0
> at 
> org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:180)
> at 
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:195)
> ... 16 more
> Caused by: org.eclipse.aether.collection.DependencyCollectionException: 
> Failed to collect dependencies at com.foo:dependency_1:jar:1.2.3-SNAPSHOT -> 
> com.foo:dependency_2:jar:1.2.3-SNAPSHOT -> 
> com.foo:dependency_3:jar:1.2.3-SNAPSHOT -> 
> com.foo.somegroup:dependency_4:jar:3.0.0
> at 
> org.eclipse.aether.internal.impl.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:291)
> at 
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies(DefaultRepositorySystem.java:316)
> at 
> 

[jira] [Updated] (MSITE-828) Jdk 1.8 required

[*$^¨%`£]

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

Olivier Lamy (*$^¨%`£) updated MSITE-828:
-
Summary: Jdk 1.8 required  (was: Jdk 1.8 required / Upgrade Jetty Version 
9.4.12)

> Jdk 1.8 required
> 
>
> Key: MSITE-828
> URL: https://issues.apache.org/jira/browse/MSITE-828
> Project: Maven Site Plugin
>  Issue Type: Task
>Reporter: Olivier Lamy (*$^¨%`£)
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Major
>




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

[jira] [Commented] (SUREFIRE-1309) Clarify %regex

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SUREFIRE-1309:
--

Tibor17 commented on a change in pull request #138: SUREFIRE-1309: Clarifying 
use of regular expressions for inclusion/exclusion
URL: https://github.com/apache/maven-surefire/pull/138#discussion_r233009914
 
 

 ##
 File path: 
maven-surefire-plugin/src/site/apt/examples/inclusion-exclusion.apt.vm
 ##
 @@ -164,7 +164,16 @@ Inclusions and Exclusions of Tests
 +---+
 
   Note the syntax <<<%regex[expr]>>>, where <<>> is the actual 
expression and the rest is just wrapping. Also
-  note that regex matches are done over <<<*.class>>> files and not 
<<<*.java>>> files.
+  note the following about the use of regular expressions:
+
+   * Regex matches are done over <<<*.class>>> files and not <<<*.java>>> files
+
+   * Regex matches are done over paths using slashes ("<<>>") and not 
package names using dots ("<<<.>>>"), so the
+  "<<<.>>>" in <<>> is a regex metacharacter, which 
happens to match any character, notably
+  the (forward) slashes ("<<>>") that make up the path. Slashes here 
are , even on Windows
 
 Review comment:
   @bturner 
   It will run the same as before except having slashes and `.class` nor 
`.java`.
   We have a huge number of unit and integration tests. So. We try to pass them 
successfully.


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


> Clarify %regex
> --
>
> Key: SUREFIRE-1309
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1309
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.19.1
> Environment: Probably any environment
>Reporter: Sander Verhagen
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.20
>
>
> It would be good to clarify the {{%regex ...}} feature:
> 1. While it is said to be regular expression, it really is a {{regular 
> expression + ".class"}} kind of thing. This does not work (while it is proper 
> regex):
> {noformat}.+\.class{noformat} The following works (while it is not proper 
> regex): {noformat}.+.class{noformat}
> 2. Clarify that one is supposed to match slashes between packages and class 
> name, not periods. The following [current 
> documentation|http://maven.apache.org/components/surefire/maven-surefire-plugin/examples/inclusion-exclusion.html]
>  doesn't clarify that by just using "{{.*}}": 
> {noformat}!%regex[pkg.*Slow.*.class]{noformat}
> 3. Clarify what the expectations are in terms of escaping characters
> I just spend literally ten hours figuring out a complex regex, going into 
> TeamCity (which by itself complicated the troubleshooting for me), and the 
> documentation could have saved my butt, here.



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

[jira] [Commented] (SUREFIRE-1309) Clarify %regex

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SUREFIRE-1309:
--

Tibor17 commented on a change in pull request #138: SUREFIRE-1309: Clarifying 
use of regular expressions for inclusion/exclusion
URL: https://github.com/apache/maven-surefire/pull/138#discussion_r233009914
 
 

 ##
 File path: 
maven-surefire-plugin/src/site/apt/examples/inclusion-exclusion.apt.vm
 ##
 @@ -164,7 +164,16 @@ Inclusions and Exclusions of Tests
 +---+
 
   Note the syntax <<<%regex[expr]>>>, where <<>> is the actual 
expression and the rest is just wrapping. Also
-  note that regex matches are done over <<<*.class>>> files and not 
<<<*.java>>> files.
+  note the following about the use of regular expressions:
+
+   * Regex matches are done over <<<*.class>>> files and not <<<*.java>>> files
+
+   * Regex matches are done over paths using slashes ("<<>>") and not 
package names using dots ("<<<.>>>"), so the
+  "<<<.>>>" in <<>> is a regex metacharacter, which 
happens to match any character, notably
+  the (forward) slashes ("<<>>") that make up the path. Slashes here 
are , even on Windows
 
 Review comment:
   @bturner 
   It will run the same as before except that there would not be slashes and 
`.class` nor `.java`.
   We have a huge number of unit and integration tests. So. We try to pass them 
successfully.


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


> Clarify %regex
> --
>
> Key: SUREFIRE-1309
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1309
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.19.1
> Environment: Probably any environment
>Reporter: Sander Verhagen
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.20
>
>
> It would be good to clarify the {{%regex ...}} feature:
> 1. While it is said to be regular expression, it really is a {{regular 
> expression + ".class"}} kind of thing. This does not work (while it is proper 
> regex):
> {noformat}.+\.class{noformat} The following works (while it is not proper 
> regex): {noformat}.+.class{noformat}
> 2. Clarify that one is supposed to match slashes between packages and class 
> name, not periods. The following [current 
> documentation|http://maven.apache.org/components/surefire/maven-surefire-plugin/examples/inclusion-exclusion.html]
>  doesn't clarify that by just using "{{.*}}": 
> {noformat}!%regex[pkg.*Slow.*.class]{noformat}
> 3. Clarify what the expectations are in terms of escaping characters
> I just spend literally ten hours figuring out a complex regex, going into 
> TeamCity (which by itself complicated the troubleshooting for me), and the 
> documentation could have saved my butt, here.



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

[jira] [Created] (MSOURCES-119) Archiving to jar is very slow

[Claes Nordmark (JIRA)]

Claes Nordmark created MSOURCES-119:
---

 Summary: Archiving to jar is very slow
 Key: MSOURCES-119
 URL: https://issues.apache.org/jira/browse/MSOURCES-119
 Project: Maven Source Plugin
  Issue Type: Bug
Affects Versions: 3.0.0
 Environment: RedHat 7
Reporter: Claes Nordmark


Doing a stackdump while "maven-source-plugin:3.0.0:jar-no-fork 
(attach-sources)" shows thread spending a lot of time in 
UnixNativeDispatcher.getgrgid.

This was not visible in java 8 and source plugin version 2.4.

Our previous build time has been increased from 5min to 3h 30min.

Tested version Java 11 and 3.0.0 of maven-source-plugin

maven config:
{code:java}
 
 org.apache.maven.plugins
 maven-source-plugin
 3.0.0
 
   
 attach-sources
 
   jar-no-fork
 
   
 
 {code}
{{java.lang.Thread.State: RUNNABLE}}
{{ at sun.nio.fs.UnixNativeDispatcher.getgrgid(java.base@11/Native Method)}}
{{ at 
sun.nio.fs.UnixUserPrincipals.fromGid(java.base@11/UnixUserPrincipals.java:129)}}
{{ at 
sun.nio.fs.UnixFileAttributes.group(java.base@11/UnixFileAttributes.java:208)}}
{{ - locked <0x0006b0773fd8> (a sun.nio.fs.UnixFileAttributes)}}
{{ at 
sun.nio.fs.UnixFileAttributeViews$Posix.addRequestedPosixAttributes(java.base@11/UnixFileAttributeViews.java:214)}}
{{ at 
sun.nio.fs.UnixFileAttributeViews$Unix.readAttributes(java.base@11/UnixFileAttributeViews.java:362)}}
{{ at 
sun.nio.fs.AbstractFileSystemProvider.readAttributes(java.base@11/AbstractFileSystemProvider.java:94)}}
{{ at java.nio.file.Files.readAttributes(java.base@11/Files.java:1996)}}
{{ at 
org.codehaus.plexus.components.io.attributes.Java7FileAttributes.(Java7FileAttributes.java:65)}}
{{ at 
org.codehaus.plexus.components.io.resources.PlexusIoFileResourceCollection.addResourcesJava7(PlexusIoFileResourceCollection.java:192)}}
{{ at 
org.codehaus.plexus.components.io.resources.PlexusIoFileResourceCollection.getResources(PlexusIoFileResourceCollection.java:287)}}
{{ at 
org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:504)}}
{{ at 
org.apache.maven.plugins.source.AbstractSourceJarMojo.packageSources(AbstractSourceJarMojo.java:287)}}



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

[jira] [Updated] (MSITE-828) Jdk 1.8 required

[*$^¨%`£]

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

Olivier Lamy (*$^¨%`£) updated MSITE-828:
-
Fix Version/s: 3.8

> Jdk 1.8 required
> 
>
> Key: MSITE-828
> URL: https://issues.apache.org/jira/browse/MSITE-828
> Project: Maven Site Plugin
>  Issue Type: Task
>Reporter: Olivier Lamy (*$^¨%`£)
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Major
> Fix For: 3.8
>
>




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

[jira] [Commented] (MSITE-828) Jdk 1.8 required

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSITE-828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16685005#comment-16685005
 ] 

ASF GitHub Bot commented on MSITE-828:
--

olamy commented on issue #3: [MSITE-828] Upgrade jetty to recent version. 
Update to java 1.8 (required for jetty)
URL: https://github.com/apache/maven-site-plugin/pull/3#issuecomment-438218710
 
 
   a bit of paperwork for sure :) 
https://issues.apache.org/jira/browse/MSITE-829
   jetty-9.2.x is EOL so nothing will be fixed


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


> Jdk 1.8 required
> 
>
> Key: MSITE-828
> URL: https://issues.apache.org/jira/browse/MSITE-828
> Project: Maven Site Plugin
>  Issue Type: Task
>Reporter: Olivier Lamy (*$^¨%`£)
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Major
> Fix For: 3.8
>
>




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

[jira] [Commented] (MSITE-829) Upgrade Jetty Version 9.4.12

[*$^¨%`£]

[ 
https://issues.apache.org/jira/browse/MSITE-829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16685021#comment-16685021
 ] 

Olivier Lamy (*$^¨%`£) commented on MSITE-829:
--

pr https://github.com/apache/maven-site-plugin/pull/3

> Upgrade Jetty Version 9.4.12
> 
>
> Key: MSITE-829
> URL: https://issues.apache.org/jira/browse/MSITE-829
> Project: Maven Site Plugin
>  Issue Type: Task
>Reporter: Olivier Lamy (*$^¨%`£)
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Major
> Fix For: 3.8
>
>




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

[GitHub] Tibor17 commented on a change in pull request #138: SUREFIRE-1309: Clarifying use of regular expressions for inclusion/exclusion

[GitBox]

Tibor17 commented on a change in pull request #138: SUREFIRE-1309: Clarifying 
use of regular expressions for inclusion/exclusion
URL: https://github.com/apache/maven-surefire/pull/138#discussion_r233024399
 
 

 ##
 File path: 
maven-surefire-plugin/src/site/apt/examples/inclusion-exclusion.apt.vm
 ##
 @@ -164,7 +164,16 @@ Inclusions and Exclusions of Tests
 +---+
 
   Note the syntax <<<%regex[expr]>>>, where <<>> is the actual 
expression and the rest is just wrapping. Also
-  note that regex matches are done over <<<*.class>>> files and not 
<<<*.java>>> files.
+  note the following about the use of regular expressions:
+
+   * Regex matches are done over <<<*.class>>> files and not <<<*.java>>> files
+
+   * Regex matches are done over paths using slashes ("<<>>") and not 
package names using dots ("<<<.>>>"), so the
+  "<<<.>>>" in <<>> is a regex metacharacter, which 
happens to match any character, notably
+  the (forward) slashes ("<<>>") that make up the path. Slashes here 
are , even on Windows
 
 Review comment:
   @bturner 
   You can track the progress in 
[SUREFIRE-1292](https://issues.apache.org/jira/browse/SUREFIRE-1292) and 
[SUREFIRE-526](https://issues.apache.org/jira/browse/SUREFIRE-526).


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] (SUREFIRE-1309) Clarify %regex

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SUREFIRE-1309:
--

Tibor17 commented on a change in pull request #138: SUREFIRE-1309: Clarifying 
use of regular expressions for inclusion/exclusion
URL: https://github.com/apache/maven-surefire/pull/138#discussion_r233024399
 
 

 ##
 File path: 
maven-surefire-plugin/src/site/apt/examples/inclusion-exclusion.apt.vm
 ##
 @@ -164,7 +164,16 @@ Inclusions and Exclusions of Tests
 +---+
 
   Note the syntax <<<%regex[expr]>>>, where <<>> is the actual 
expression and the rest is just wrapping. Also
-  note that regex matches are done over <<<*.class>>> files and not 
<<<*.java>>> files.
+  note the following about the use of regular expressions:
+
+   * Regex matches are done over <<<*.class>>> files and not <<<*.java>>> files
+
+   * Regex matches are done over paths using slashes ("<<>>") and not 
package names using dots ("<<<.>>>"), so the
+  "<<<.>>>" in <<>> is a regex metacharacter, which 
happens to match any character, notably
+  the (forward) slashes ("<<>>") that make up the path. Slashes here 
are , even on Windows
 
 Review comment:
   @bturner 
   You can track the progress in 
[SUREFIRE-1292](https://issues.apache.org/jira/browse/SUREFIRE-1292) and 
[SUREFIRE-526](https://issues.apache.org/jira/browse/SUREFIRE-526).


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


> Clarify %regex
> --
>
> Key: SUREFIRE-1309
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1309
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.19.1
> Environment: Probably any environment
>Reporter: Sander Verhagen
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.20
>
>
> It would be good to clarify the {{%regex ...}} feature:
> 1. While it is said to be regular expression, it really is a {{regular 
> expression + ".class"}} kind of thing. This does not work (while it is proper 
> regex):
> {noformat}.+\.class{noformat} The following works (while it is not proper 
> regex): {noformat}.+.class{noformat}
> 2. Clarify that one is supposed to match slashes between packages and class 
> name, not periods. The following [current 
> documentation|http://maven.apache.org/components/surefire/maven-surefire-plugin/examples/inclusion-exclusion.html]
>  doesn't clarify that by just using "{{.*}}": 
> {noformat}!%regex[pkg.*Slow.*.class]{noformat}
> 3. Clarify what the expectations are in terms of escaping characters
> I just spend literally ten hours figuring out a complex regex, going into 
> TeamCity (which by itself complicated the troubleshooting for me), and the 
> documentation could have saved my butt, here.



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

[jira] [Created] (MSITE-829) Upgrade Jetty Version 9.4.12

[*$^¨%`£]

Olivier Lamy (*$^¨%`£) created MSITE-829:


 Summary: Upgrade Jetty Version 9.4.12
 Key: MSITE-829
 URL: https://issues.apache.org/jira/browse/MSITE-829
 Project: Maven Site Plugin
  Issue Type: Task
Reporter: Olivier Lamy (*$^¨%`£)
Assignee: Olivier Lamy (*$^¨%`£)






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

[GitHub] Tibor17 commented on a change in pull request #138: SUREFIRE-1309: Clarifying use of regular expressions for inclusion/exclusion

[GitBox]

Tibor17 commented on a change in pull request #138: SUREFIRE-1309: Clarifying 
use of regular expressions for inclusion/exclusion
URL: https://github.com/apache/maven-surefire/pull/138#discussion_r233009914
 
 

 ##
 File path: 
maven-surefire-plugin/src/site/apt/examples/inclusion-exclusion.apt.vm
 ##
 @@ -164,7 +164,16 @@ Inclusions and Exclusions of Tests
 +---+
 
   Note the syntax <<<%regex[expr]>>>, where <<>> is the actual 
expression and the rest is just wrapping. Also
-  note that regex matches are done over <<<*.class>>> files and not 
<<<*.java>>> files.
+  note the following about the use of regular expressions:
+
+   * Regex matches are done over <<<*.class>>> files and not <<<*.java>>> files
+
+   * Regex matches are done over paths using slashes ("<<>>") and not 
package names using dots ("<<<.>>>"), so the
+  "<<<.>>>" in <<>> is a regex metacharacter, which 
happens to match any character, notably
+  the (forward) slashes ("<<>>") that make up the path. Slashes here 
are , even on Windows
 
 Review comment:
   @bturner 
   It will run the same as before except having slashes and `.class` nor 
`.java`.
   We have a huge number of unit and integration tests. So. We try to pass them 
successfully.


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

[GitHub] Tibor17 commented on a change in pull request #138: SUREFIRE-1309: Clarifying use of regular expressions for inclusion/exclusion

[GitBox]

Tibor17 commented on a change in pull request #138: SUREFIRE-1309: Clarifying 
use of regular expressions for inclusion/exclusion
URL: https://github.com/apache/maven-surefire/pull/138#discussion_r233009914
 
 

 ##
 File path: 
maven-surefire-plugin/src/site/apt/examples/inclusion-exclusion.apt.vm
 ##
 @@ -164,7 +164,16 @@ Inclusions and Exclusions of Tests
 +---+
 
   Note the syntax <<<%regex[expr]>>>, where <<>> is the actual 
expression and the rest is just wrapping. Also
-  note that regex matches are done over <<<*.class>>> files and not 
<<<*.java>>> files.
+  note the following about the use of regular expressions:
+
+   * Regex matches are done over <<<*.class>>> files and not <<<*.java>>> files
+
+   * Regex matches are done over paths using slashes ("<<>>") and not 
package names using dots ("<<<.>>>"), so the
+  "<<<.>>>" in <<>> is a regex metacharacter, which 
happens to match any character, notably
+  the (forward) slashes ("<<>>") that make up the path. Slashes here 
are , even on Windows
 
 Review comment:
   @bturner 
   It will run the same as before except that there would not be slashes and 
`.class` nor `.java`.
   We have a huge number of unit and integration tests. So. We try to pass them 
successfully.


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] (WAGON-537) Maven transfer speed of large artifacts is slow due to unsuitable buffer strategy

[Michael Osipov (JIRA)]

[ 
https://issues.apache.org/jira/browse/WAGON-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16685104#comment-16685104
 ] 

Michael Osipov commented on WAGON-537:
--

I will test the upload with curl in the next couple of days. The [progress 
monitor|https://github.com/apache/maven/blob/master/maven-embedder/src/main/java/org/apache/maven/cli/transfer/AbstractMavenTransferListener.java]
 has been reworked by me some time ago. Do you think it makes sense to peg the 
buffer size to the granularity of the output formatter. Why update the if the 
decimal does not change?!

> Maven transfer speed of large artifacts is slow due to unsuitable buffer 
> strategy
> -
>
> Key: WAGON-537
> URL: https://issues.apache.org/jira/browse/WAGON-537
> Project: Maven Wagon
>  Issue Type: Improvement
>  Components: wagon-http, wagon-provider-api
>Affects Versions: 3.2.0
> Environment: Windows 10, JDK 1.8, Nexus  Artifact store > 100MB/s 
> network connection.
>Reporter: Olaf Otto
>Assignee: Michael Osipov
>Priority: Major
>  Labels: perfomance
> Fix For: 3.2.1
>
> Attachments: wagon-issue.png
>
>
> We are using maven for build process automation with docker. This sometimes 
> involves uploading and downloading artifacts with a few gigabytes in size. 
> Here, maven's transfer speed is consistently and reproducibly slow. For 
> instance, an artifact with 7,5 GB in size took almost two hours to transfer 
> in spite of a 100 MB/s connection with respective reproducible download speed 
> from the remote nexus artifact repository when using a browser to download. 
> The same is true when uploding such an artifact.
> I have investigated the issue using JProfiler. The result shows an issue in 
> AbstractWagon's transfer( Resource resource, InputStream input, OutputStream 
> output, int requestType, long maxSize ) method used for remote artifacts and 
> the same issue in AbstractHttpClientWagon#writeTo(OutputStream).
> Here, the input stream is read in a loop using a 4 Kb buffer. Whenever data 
> is received, the received data is pushed to downstream listeners via 
> fireTransferProgress. These listeners (or rather consumers) perform expensive 
> tasks.
> Now, the underlying InputStream implementation used in transfer will return 
> calls to read(buffer, offset, length) as soon as *some* data is available. 
> That is, fireTransferProgress may well be invoked with an average number of 
> bytes less than half the buffer capacity (this varies with the underlying 
> network and hardware architecture). Consequently, fireTransferProgress is 
> invoked *millions of times* for large files. As this is a blocking operation, 
> the time spent in fireTransferProgress dominates and drastically slows down 
> the transfers by at least one order of magnitude. 
> !wagon-issue.png! 
> In our case, we found download speed reduced from a theoretical optimum of 
> ~80 seconds to to more than 3200 seconds.
> From an architectural perspective, I would not want to make the consumers / 
> listeners invoked via fireTransferProgress aware of their potential impact on 
> download speed, but rather refactor the transfer method such that it uses a 
> buffer strategy reducing the the number of fireTransferProgress invocations. 
> This should be done with regard to the expected file size of the transfer, 
> such that fireTransferProgress is invoked often enough but not to frequent.



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

[jira] [Updated] (MSITE-829) Upgrade Jetty Version 9.4.12

[*$^¨%`£]

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

Olivier Lamy (*$^¨%`£) updated MSITE-829:
-
Fix Version/s: 3.8

> Upgrade Jetty Version 9.4.12
> 
>
> Key: MSITE-829
> URL: https://issues.apache.org/jira/browse/MSITE-829
> Project: Maven Site Plugin
>  Issue Type: Task
>Reporter: Olivier Lamy (*$^¨%`£)
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Major
> Fix For: 3.8
>
>




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

[jira] [Updated] (MSITE-829) Upgrade Jetty to 9.4.12

[Michael Osipov (JIRA)]

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

Michael Osipov updated MSITE-829:
-
Summary: Upgrade Jetty to 9.4.12  (was: Upgrade Jetty Version 9.4.12)

> Upgrade Jetty to 9.4.12
> ---
>
> Key: MSITE-829
> URL: https://issues.apache.org/jira/browse/MSITE-829
> Project: Maven Site Plugin
>  Issue Type: Task
>Reporter: Olivier Lamy (*$^¨%`£)
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Major
> Fix For: 3.8
>
>




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

[jira] [Created] (MJAR-259) Archiving to jar is very slow

[Claes Nordmark (JIRA)]

Claes Nordmark created MJAR-259:
---

 Summary: Archiving to jar is very slow
 Key: MJAR-259
 URL: https://issues.apache.org/jira/browse/MJAR-259
 Project: Maven JAR Plugin
  Issue Type: Bug
Affects Versions: 3.1.0
 Environment: Redhat7
Reporter: Claes Nordmark


Doing a stackdump while "maven-jar-plugin:3.1.0:jar (default-jar)" shows thread 
spending a lot of time in UnixNativeDispatcher.getgrgid.

This was not visible in java 8 and jar plugin version 2.6.

Our previous build time has been increased from 5min to 3h 30min.

Tested version Java 11 and 3.1.0 of maven-jar-plugin

 
{code:java}

org.apache.maven.plugins
maven-jar-plugin
${maven.jar.plugin.version}

 true
 
  true
  
true
  
 


 
{code}
 
{code:java}
java.lang.Thread.State: RUNNABLE
 at sun.nio.fs.UnixNativeDispatcher.getgrgid(java.base@11/Native Method)
 at 
sun.nio.fs.UnixUserPrincipals.fromGid(java.base@11/UnixUserPrincipals.java:129)
 at 
sun.nio.fs.UnixFileAttributes.group(java.base@11/UnixFileAttributes.java:208)
 - locked <0x00067c2b31f0> (a sun.nio.fs.UnixFileAttributes)
 at 
sun.nio.fs.UnixFileAttributeViews$Posix.addRequestedPosixAttributes(java.base@11/UnixFileAttributeViews.java:214)
 at 
sun.nio.fs.UnixFileAttributeViews$Unix.readAttributes(java.base@11/UnixFileAttributeViews.java:362)
 at 
sun.nio.fs.AbstractFileSystemProvider.readAttributes(java.base@11/AbstractFileSystemProvider.java:94)
 at java.nio.file.Files.readAttributes(java.base@11/Files.java:1996)
 at 
org.codehaus.plexus.components.io.attributes.FileAttributes.(FileAttributes.java:67)
 at 
org.codehaus.plexus.components.io.resources.PlexusIoFileResourceCollection.addResources(PlexusIoFileResourceCollection.java:156)
 at 
org.codehaus.plexus.components.io.resources.PlexusIoFileResourceCollection.getResources(PlexusIoFileResourceCollection.java:254)
 at 
org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:506)
 at 
org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:256)
 at 
org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:234)
 at 
org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:987)
 at 
org.apache.maven.archiver.MavenArchiver.createArchive(MavenArchiver.java:649)
 at 
org.apache.maven.plugins.jar.AbstractJarMojo.createArchive(AbstractJarMojo.java:224)
 at 
org.apache.maven.plugins.jar.AbstractJarMojo.execute(AbstractJarMojo.java:255)
 at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
 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.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:200)
 at 
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:196)
 at java.util.concurrent.FutureTask.run(java.base@11/FutureTask.java:264)
 at 
java.util.concurrent.Executors$RunnableAdapter.call(java.base@11/Executors.java:515)
 at java.util.concurrent.FutureTask.run(java.base@11/FutureTask.java:264)
 at 
java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11/ThreadPoolExecutor.java:1128)
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11/ThreadPoolExecutor.java:628)
 at java.lang.Thread.run(java.base@11/Thread.java:834){code}



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

[GitHub] jglick commented on a change in pull request #199: Surefire 1593

[GitBox]

jglick commented on a change in pull request #199: Surefire 1593
URL: https://github.com/apache/maven-surefire/pull/199#discussion_r233067360
 
 

 ##
 File path: 
maven-surefire-common/src/test/java/org/apache/maven/plugin/surefire/booterclient/JarManifestForkConfigurationTest.java
 ##
 @@ -0,0 +1,190 @@
+package org.apache.maven.plugin.surefire.booterclient;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.io.File;
+import java.net.URI;
+
+import 
org.apache.maven.plugin.surefire.booterclient.output.InPluginProcessDumpSingleton;
+import static org.fest.assertions.Assertions.assertThat;
+import org.junit.Test;
+import org.junit.runner.RunWith;
+import static org.mockito.ArgumentMatchers.any;
+import static org.mockito.ArgumentMatchers.anyString;
+import static org.powermock.api.mockito.PowerMockito.mock;
+import static org.powermock.api.mockito.PowerMockito.mockStatic;
+import static org.powermock.api.mockito.PowerMockito.when;
+import org.powermock.core.classloader.annotations.PrepareForTest;
+import org.powermock.modules.junit4.PowerMockRunner;
+
+/**
+ * Unit tests for {@link JarManifestForkConfiguration}.
+ */
+@RunWith( PowerMockRunner.class )
+@PrepareForTest( { JarManifestForkConfiguration.class, 
InPluginProcessDumpSingleton.class } )
+public class JarManifestForkConfigurationTest
+{
+private static final String BASE_DIR = System.getProperty( "user.dir" );
+
+@Test
+public void relativeClasspathUnixSimple()
+throws Exception
+{
+mockStatic( JarManifestForkConfiguration.class );
+String parent = "/home/me/prj/target/surefire";
+String classPathElement = 
"/home/me/.m2/repository/grp/art/1.0/art-1.0.jar";
+when( JarManifestForkConfiguration.relativize( parent, 
classPathElement ) )
+.thenReturn( "../../../.m2/repository/grp/art/1.0/art-1.0.jar" 
);
+when( JarManifestForkConfiguration.toClasspathElementUri( anyString(), 
anyString(), any( File.class ) ) )
+.thenCallRealMethod();
+File dump = new File( BASE_DIR, "target/test-dump" );
+//noinspection ResultOfMethodCallIgnored
+dump.mkdir();
+assertThat( JarManifestForkConfiguration.toClasspathElementUri( 
parent, classPathElement, dump ) )
+.isEqualTo( "../../../.m2/repository/grp/art/1.0/art-1.0.jar" 
);
+}
+
+@Test
+public void relativeClasspathUnixTricky()
+throws Exception
+{
+mockStatic( JarManifestForkConfiguration.class );
+String parent = "/home/me/prj/target/surefire";
+String classPathElement = "/the Maven repo/grp/art/1.0/art-1.0.jar";
+when( JarManifestForkConfiguration.relativize( parent, 
classPathElement ) )
+.thenReturn( "../../../../../the Maven 
repo/grp/art/1.0/art-1.0.jar" );
+when( JarManifestForkConfiguration.toClasspathElementUri( anyString(), 
anyString(), any( File.class ) ) )
+.thenCallRealMethod();
+File dump = new File( BASE_DIR, "target/test-dump" );
+assertThat( JarManifestForkConfiguration.toClasspathElementUri( 
parent, classPathElement, dump ) )
+.isEqualTo( 
"../../../../../the%20Maven%20repo/grp/art/1.0/art-1.0.jar" );
+}
+
+@Test
+public void relativeClasspathWindowsSimple()
+throws Exception
+{
+mockStatic( JarManifestForkConfiguration.class );
+String parent = "C:\\Windows\\Temp\\surefire";
+String classPathElement = 
"C:\\Users\\me\\.m2\\repository\\grp\\art\\1.0\\art-1.0.jar";
+when( JarManifestForkConfiguration.relativize( parent, 
classPathElement ) )
+.thenReturn( 
"..\\..\\..\\Users\\me\\.m2\\repository\\grp\\art\\1.0\\art-1.0.jar" );
+when( JarManifestForkConfiguration.toClasspathElementUri( anyString(), 
anyString(), any( File.class ) ) )
+.thenCallRealMethod();
+File dump = new File( BASE_DIR, "target/test-dump" );
+assertThat( JarManifestForkConfiguration.toClasspathElementUri( 
parent, classPathElement, dump ) )
+.isEqualTo( 
"../../../Users/me/.m2/repository/grp/art/1.0/art-1.0.jar" );
+}
+
+@Test
+

[GitHub] jglick commented on a change in pull request #199: Surefire 1593

[GitBox]

jglick commented on a change in pull request #199: Surefire 1593
URL: https://github.com/apache/maven-surefire/pull/199#discussion_r233068986
 
 

 ##
 File path: 
maven-surefire-common/src/test/java/org/apache/maven/plugin/surefire/booterclient/JarManifestForkConfigurationTest.java
 ##
 @@ -0,0 +1,190 @@
+package org.apache.maven.plugin.surefire.booterclient;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.io.File;
+import java.net.URI;
+
+import 
org.apache.maven.plugin.surefire.booterclient.output.InPluginProcessDumpSingleton;
+import static org.fest.assertions.Assertions.assertThat;
+import org.junit.Test;
+import org.junit.runner.RunWith;
+import static org.mockito.ArgumentMatchers.any;
+import static org.mockito.ArgumentMatchers.anyString;
+import static org.powermock.api.mockito.PowerMockito.mock;
+import static org.powermock.api.mockito.PowerMockito.mockStatic;
+import static org.powermock.api.mockito.PowerMockito.when;
+import org.powermock.core.classloader.annotations.PrepareForTest;
+import org.powermock.modules.junit4.PowerMockRunner;
+
+/**
+ * Unit tests for {@link JarManifestForkConfiguration}.
+ */
+@RunWith( PowerMockRunner.class )
+@PrepareForTest( { JarManifestForkConfiguration.class, 
InPluginProcessDumpSingleton.class } )
+public class JarManifestForkConfigurationTest
+{
+private static final String BASE_DIR = System.getProperty( "user.dir" );
 
 Review comment:
   This will pollute the CWD when `mvn` is run using `-f` rather than 
defaulting the basedir.
   
   If you want a temporary directory, I would suggest using the 
`TemporaryFolder` rule.


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

[GitHub] jglick commented on issue #198: [SUREFIRE-1593] Correcting relativization logic to produce valid URIs on Windows

[GitBox]

jglick commented on issue #198: [SUREFIRE-1593] Correcting relativization logic 
to produce valid URIs on Windows
URL: https://github.com/apache/maven-surefire/pull/198#issuecomment-438296318
 
 
   > Oracle used examples with relative paths only.
   
   Yes, and that is what #197 attempts to do. It falls back to the original 
behavior of absolute URIs only when relativization fails, typically due to 
Windows cross-drive issues.


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] (MENFORCER-319) UTF-8 BOM in pom.xml breaks banDuplicatePomDependencyVersions rule

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MENFORCER-319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16685449#comment-16685449
 ] 

ASF GitHub Bot commented on MENFORCER-319:
--

wilx opened a new pull request #45: [MENFORCER-319] Handle UTF-8 BOM when 
parsing pom.xml files
URL: https://github.com/apache/maven-enforcer/pull/45
 
 
   Handle parsing of pom.xml in BanDuplicatePomDependencyVersions.java
   similarly to how actual Maven model parser handles it to fix handling
   of pom.xml files with UTF-8 BOM.
   
   Following this checklist to help us incorporate your 
   contribution quickly and easily:
   
- [x] Make sure there is a [JIRA 
issue](https://issues.apache.org/jira/browse/MENFORCER) filed 
  for the change (usually before you start working on it).  Trivial 
changes like typos do not 
  require a JIRA issue.  Your pull request should address just this 
issue, without 
  pulling in other changes. 
[MENFORCER-319](https://issues.apache.org/jira/browse/MENFORCER-319)
- [ ] Each commit in the pull request should have a meaningful subject line 
and body.
- [ ] Format the pull request title like `[MENFORCER-XXX] - Fixes bug in 
ApproximateQuantiles`,
  where you replace `MENFORCER-XXX` with the appropriate JIRA issue. 
Best practice
  is to use the JIRA issue title in the pull request title and in the 
first line of the 
  commit message.
- [ ] Write a pull request description that is detailed enough to 
understand what the pull request does, how, and why.
- [ ] Run `mvn clean verify` to make sure basic checks pass. A more 
thorough check will 
  be performed on your pull request automatically.
   
   If your pull request is about ~20 lines of code you don't need to sign an
   [Individual Contributor License 
Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure
   please ask on the developers list.
   
   To make clear that you license your contribution under 
   the [Apache License Version 2.0, January 
2004](http://www.apache.org/licenses/LICENSE-2.0)
   you have to acknowledge this by using the following check-box.
   
- [x] I hereby declare this contribution to be licenced under the [Apache 
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
   
- [ ] In any other case, please file an [Apache Individual Contributor 
License Agreement](https://www.apache.org/licenses/icla.pdf).
   
   


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


> UTF-8 BOM in pom.xml breaks banDuplicatePomDependencyVersions rule
> --
>
> Key: MENFORCER-319
> URL: https://issues.apache.org/jira/browse/MENFORCER-319
> Project: Maven Enforcer Plugin
>  Issue Type: Bug
>  Components: Standard Rules
>Affects Versions: 3.0.0-M2
>Reporter: Václav Haisman
>Priority: Major
> Attachments: 
> Handle_parsing_of_pom_xml_in_BanDuplicatePomDependencyVersions_java_similarly_to_how_actua.patch,
>  pom.xml
>
>
> Having UTF-8 BOM at the beginning of {{pom.xml}} causes the 
> banDuplicatePomDependencyVersions rule to fail to parse the file with the 
> following exception being shown by {{-X}} output:
> {noformat}
> [DEBUG] Adding failure due to exception
> org.apache.maven.enforcer.rule.api.EnforcerRuleException: Unable to retrieve 
> the MavenProject:
> at 
> org.apache.maven.plugins.enforcer.BanDuplicatePomDependencyVersions.execute 
> (BanDuplicatePomDependencyVersions.java:87)
> at org.apache.maven.plugins.enforcer.EnforceMojo.execute 
> (EnforceMojo.java:194)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
> (DefaultBuildPluginManager.java:137)
> 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:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at 

[GitHub] wilx opened a new pull request #45: [MENFORCER-319] Handle UTF-8 BOM when parsing pom.xml files

[GitBox]

wilx opened a new pull request #45: [MENFORCER-319] Handle UTF-8 BOM when 
parsing pom.xml files
URL: https://github.com/apache/maven-enforcer/pull/45
 
 
   Handle parsing of pom.xml in BanDuplicatePomDependencyVersions.java
   similarly to how actual Maven model parser handles it to fix handling
   of pom.xml files with UTF-8 BOM.
   
   Following this checklist to help us incorporate your 
   contribution quickly and easily:
   
- [x] Make sure there is a [JIRA 
issue](https://issues.apache.org/jira/browse/MENFORCER) filed 
  for the change (usually before you start working on it).  Trivial 
changes like typos do not 
  require a JIRA issue.  Your pull request should address just this 
issue, without 
  pulling in other changes. 
[MENFORCER-319](https://issues.apache.org/jira/browse/MENFORCER-319)
- [ ] Each commit in the pull request should have a meaningful subject line 
and body.
- [ ] Format the pull request title like `[MENFORCER-XXX] - Fixes bug in 
ApproximateQuantiles`,
  where you replace `MENFORCER-XXX` with the appropriate JIRA issue. 
Best practice
  is to use the JIRA issue title in the pull request title and in the 
first line of the 
  commit message.
- [ ] Write a pull request description that is detailed enough to 
understand what the pull request does, how, and why.
- [ ] Run `mvn clean verify` to make sure basic checks pass. A more 
thorough check will 
  be performed on your pull request automatically.
   
   If your pull request is about ~20 lines of code you don't need to sign an
   [Individual Contributor License 
Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure
   please ask on the developers list.
   
   To make clear that you license your contribution under 
   the [Apache License Version 2.0, January 
2004](http://www.apache.org/licenses/LICENSE-2.0)
   you have to acknowledge this by using the following check-box.
   
- [x] I hereby declare this contribution to be licenced under the [Apache 
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
   
- [ ] In any other case, please file an [Apache Individual Contributor 
License Agreement](https://www.apache.org/licenses/icla.pdf).
   
   


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

[GitHub] Tibor17 commented on a change in pull request #199: Surefire 1593

[GitBox]

Tibor17 commented on a change in pull request #199: Surefire 1593
URL: https://github.com/apache/maven-surefire/pull/199#discussion_r233115721
 
 

 ##
 File path: 
maven-surefire-common/src/test/java/org/apache/maven/plugin/surefire/booterclient/JarManifestForkConfigurationTest.java
 ##
 @@ -0,0 +1,190 @@
+package org.apache.maven.plugin.surefire.booterclient;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.io.File;
+import java.net.URI;
+
+import 
org.apache.maven.plugin.surefire.booterclient.output.InPluginProcessDumpSingleton;
+import static org.fest.assertions.Assertions.assertThat;
+import org.junit.Test;
+import org.junit.runner.RunWith;
+import static org.mockito.ArgumentMatchers.any;
+import static org.mockito.ArgumentMatchers.anyString;
+import static org.powermock.api.mockito.PowerMockito.mock;
+import static org.powermock.api.mockito.PowerMockito.mockStatic;
+import static org.powermock.api.mockito.PowerMockito.when;
+import org.powermock.core.classloader.annotations.PrepareForTest;
+import org.powermock.modules.junit4.PowerMockRunner;
+
+/**
+ * Unit tests for {@link JarManifestForkConfiguration}.
+ */
+@RunWith( PowerMockRunner.class )
+@PrepareForTest( { JarManifestForkConfiguration.class, 
InPluginProcessDumpSingleton.class } )
+public class JarManifestForkConfigurationTest
+{
+private static final String BASE_DIR = System.getProperty( "user.dir" );
 
 Review comment:
   These are files for testing purposes in target folder. Here we run the build 
`mvn install` in the root and not in a child. Even if you run this particular 
test in IntelliJIDEA, the `user.dir` is `maven-surefire-common/pom.xml`, so I 
think it is fine for this test but we can create the temporal folders in TEMP 
if you like, this does not harm the goal of the test.


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

[GitHub] Tibor17 commented on a change in pull request #199: Surefire 1593

[GitBox]

Tibor17 commented on a change in pull request #199: Surefire 1593
URL: https://github.com/apache/maven-surefire/pull/199#discussion_r233119261
 
 

 ##
 File path: 
maven-surefire-common/src/test/java/org/apache/maven/plugin/surefire/booterclient/JarManifestForkConfigurationTest.java
 ##
 @@ -0,0 +1,190 @@
+package org.apache.maven.plugin.surefire.booterclient;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.io.File;
+import java.net.URI;
+
+import 
org.apache.maven.plugin.surefire.booterclient.output.InPluginProcessDumpSingleton;
+import static org.fest.assertions.Assertions.assertThat;
+import org.junit.Test;
+import org.junit.runner.RunWith;
+import static org.mockito.ArgumentMatchers.any;
+import static org.mockito.ArgumentMatchers.anyString;
+import static org.powermock.api.mockito.PowerMockito.mock;
+import static org.powermock.api.mockito.PowerMockito.mockStatic;
+import static org.powermock.api.mockito.PowerMockito.when;
+import org.powermock.core.classloader.annotations.PrepareForTest;
+import org.powermock.modules.junit4.PowerMockRunner;
+
+/**
+ * Unit tests for {@link JarManifestForkConfiguration}.
+ */
+@RunWith( PowerMockRunner.class )
+@PrepareForTest( { JarManifestForkConfiguration.class, 
InPluginProcessDumpSingleton.class } )
+public class JarManifestForkConfigurationTest
+{
+private static final String BASE_DIR = System.getProperty( "user.dir" );
+
+@Test
+public void relativeClasspathUnixSimple()
+throws Exception
+{
+mockStatic( JarManifestForkConfiguration.class );
+String parent = "/home/me/prj/target/surefire";
+String classPathElement = 
"/home/me/.m2/repository/grp/art/1.0/art-1.0.jar";
+when( JarManifestForkConfiguration.relativize( parent, 
classPathElement ) )
+.thenReturn( "../../../.m2/repository/grp/art/1.0/art-1.0.jar" 
);
+when( JarManifestForkConfiguration.toClasspathElementUri( anyString(), 
anyString(), any( File.class ) ) )
+.thenCallRealMethod();
+File dump = new File( BASE_DIR, "target/test-dump" );
+//noinspection ResultOfMethodCallIgnored
+dump.mkdir();
+assertThat( JarManifestForkConfiguration.toClasspathElementUri( 
parent, classPathElement, dump ) )
+.isEqualTo( "../../../.m2/repository/grp/art/1.0/art-1.0.jar" 
);
+}
+
+@Test
+public void relativeClasspathUnixTricky()
+throws Exception
+{
+mockStatic( JarManifestForkConfiguration.class );
+String parent = "/home/me/prj/target/surefire";
+String classPathElement = "/the Maven repo/grp/art/1.0/art-1.0.jar";
+when( JarManifestForkConfiguration.relativize( parent, 
classPathElement ) )
+.thenReturn( "../../../../../the Maven 
repo/grp/art/1.0/art-1.0.jar" );
+when( JarManifestForkConfiguration.toClasspathElementUri( anyString(), 
anyString(), any( File.class ) ) )
+.thenCallRealMethod();
+File dump = new File( BASE_DIR, "target/test-dump" );
+assertThat( JarManifestForkConfiguration.toClasspathElementUri( 
parent, classPathElement, dump ) )
+.isEqualTo( 
"../../../../../the%20Maven%20repo/grp/art/1.0/art-1.0.jar" );
+}
+
+@Test
+public void relativeClasspathWindowsSimple()
+throws Exception
+{
+mockStatic( JarManifestForkConfiguration.class );
+String parent = "C:\\Windows\\Temp\\surefire";
+String classPathElement = 
"C:\\Users\\me\\.m2\\repository\\grp\\art\\1.0\\art-1.0.jar";
+when( JarManifestForkConfiguration.relativize( parent, 
classPathElement ) )
+.thenReturn( 
"..\\..\\..\\Users\\me\\.m2\\repository\\grp\\art\\1.0\\art-1.0.jar" );
+when( JarManifestForkConfiguration.toClasspathElementUri( anyString(), 
anyString(), any( File.class ) ) )
+.thenCallRealMethod();
+File dump = new File( BASE_DIR, "target/test-dump" );
+assertThat( JarManifestForkConfiguration.toClasspathElementUri( 
parent, classPathElement, dump ) )
+.isEqualTo( 
"../../../Users/me/.m2/repository/grp/art/1.0/art-1.0.jar" );
+}
+
+@Test
+

[GitHub] jglick commented on a change in pull request #199: Surefire 1593

[GitBox]

jglick commented on a change in pull request #199: Surefire 1593
URL: https://github.com/apache/maven-surefire/pull/199#discussion_r233073868
 
 

 ##
 File path: 
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/JarManifestForkConfiguration.java
 ##
 @@ -116,10 +116,10 @@ private File createJar( @Nonnull List classPath, 
@Nonnull String startCl
 StringBuilder cp = new StringBuilder();
 for ( Iterator it = classPath.iterator(); it.hasNext(); )
 {
-File classPathElement = new File( it.next() );
+String classPathElement = it.next();
 String uri = toClasspathElementUri( parent, classPathElement, 
dumpLogDirectory );
 cp.append( uri );
-if ( classPathElement.isDirectory() && !uri.endsWith( "/" ) )
+if ( new File( classPathElement ).isDirectory() && 
!uri.endsWith( "/" ) )
 
 Review comment:
   > `Files.isDirectory` will be more consistent with the new use of `Path`s.
   
   I chose to make a more minimal change to solve the immediate regression, 
rather than rewriting the whole class to use NIO methods.


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

[GitHub] cstamas commented on issue #198: [SUREFIRE-1593] Correcting relativization logic to produce valid URIs on Windows

[GitBox]

cstamas commented on issue #198: [SUREFIRE-1593] Correcting relativization 
logic to produce valid URIs on Windows
URL: https://github.com/apache/maven-surefire/pull/198#issuecomment-438303029
 
 
   @Tibor17 
   See 
https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#Main_Attributes


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

[GitHub] jglick commented on a change in pull request #199: Surefire 1593

[GitBox]

jglick commented on a change in pull request #199: Surefire 1593
URL: https://github.com/apache/maven-surefire/pull/199#discussion_r233070329
 
 

 ##
 File path: 
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/JarManifestForkConfiguration.java
 ##
 @@ -116,10 +116,10 @@ private File createJar( @Nonnull List classPath, 
@Nonnull String startCl
 StringBuilder cp = new StringBuilder();
 for ( Iterator it = classPath.iterator(); it.hasNext(); )
 {
-File classPathElement = new File( it.next() );
+String classPathElement = it.next();
 String uri = toClasspathElementUri( parent, classPathElement, 
dumpLogDirectory );
 cp.append( uri );
-if ( classPathElement.isDirectory() && !uri.endsWith( "/" ) )
+if ( new File( classPathElement ).isDirectory() && 
!uri.endsWith( "/" ) )
 
 Review comment:
   > we should change the method signature
   
   No, I deliberately used `String` parameters so as to make it possible to 
write unit tests. `Path`s can (as far as I know) only be constructed using 
platform-specific methods, making the tests behave differently according to the 
machine running them.


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

[GitHub] jglick commented on issue #199: Surefire 1593

[GitBox]

jglick commented on issue #199: Surefire 1593
URL: https://github.com/apache/maven-surefire/pull/199#issuecomment-438295450
 
 
   Since I cannot edit the description or title, a note to viewers: this is an 
amendment of #198.


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] (SUREFIRE-1593) 3.0.0-M1 produces invalid code sources on Windows

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SUREFIRE-1593:
--

jglick commented on issue #198: [SUREFIRE-1593] Correcting relativization logic 
to produce valid URIs on Windows
URL: https://github.com/apache/maven-surefire/pull/198#issuecomment-438296318
 
 
   > Oracle used examples with relative paths only.
   
   Yes, and that is what #197 attempts to do. It falls back to the original 
behavior of absolute URIs only when relativization fails, typically due to 
Windows cross-drive issues.


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


> 3.0.0-M1 produces invalid code sources on Windows
> -
>
> Key: SUREFIRE-1593
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1593
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: classloading, process forking
>Affects Versions: 3.0.0-M1
>Reporter: Jesse Glick
>Priority: Major
>
> The fix for SUREFIRE-1588 did not work correctly on Windows. (When 
> active—i.e., when the drive letters of the system temporary directory, per 
> SUREFIRE-1400, and the project basedir were the same.) It would produce 
> relative URIs containing {{%5C}} where {{/}} was intended.



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

[jira] [Commented] (WAGON-537) Maven transfer speed of large artifacts is slow due to unsuitable buffer strategy

[Olaf Otto (JIRA)]

[ 
https://issues.apache.org/jira/browse/WAGON-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16685265#comment-16685265
 ] 

Olaf Otto commented on WAGON-537:
-

Hi [~michael-o]

I agree that it would be great if the progress monitor only made an update if a 
decimal changes. The only potential issue I see is that if a transfer is slow, 
users may notice no activity on the console and may believe maven is "hanging".

>From an architectural perspective, I would personally not want to create any 
>dependency between TransferListeners and the transfer loop. The loop should 
>simply make sure not to invoke the listeners overly frequently as this slows 
>down transfers (the main objective of this change), and the TransferListeners 
>should do whatever they want with the data.

Perhaps one could discuss whether TransferListeners must be invoked 
synchronously during data transfer. For me, the term "Listener" implies 
asynchronism. Are there cases where a listener actively aborts transfer by 
throwing an exception, perhaps something related to checksums? If not, one 
could e.g. put progress notifications on a queue and asynchronously notify 
listeners.

> Maven transfer speed of large artifacts is slow due to unsuitable buffer 
> strategy
> -
>
> Key: WAGON-537
> URL: https://issues.apache.org/jira/browse/WAGON-537
> Project: Maven Wagon
>  Issue Type: Improvement
>  Components: wagon-http, wagon-provider-api
>Affects Versions: 3.2.0
> Environment: Windows 10, JDK 1.8, Nexus  Artifact store > 100MB/s 
> network connection.
>Reporter: Olaf Otto
>Assignee: Michael Osipov
>Priority: Major
>  Labels: perfomance
> Fix For: 3.2.1
>
> Attachments: wagon-issue.png
>
>
> We are using maven for build process automation with docker. This sometimes 
> involves uploading and downloading artifacts with a few gigabytes in size. 
> Here, maven's transfer speed is consistently and reproducibly slow. For 
> instance, an artifact with 7,5 GB in size took almost two hours to transfer 
> in spite of a 100 MB/s connection with respective reproducible download speed 
> from the remote nexus artifact repository when using a browser to download. 
> The same is true when uploding such an artifact.
> I have investigated the issue using JProfiler. The result shows an issue in 
> AbstractWagon's transfer( Resource resource, InputStream input, OutputStream 
> output, int requestType, long maxSize ) method used for remote artifacts and 
> the same issue in AbstractHttpClientWagon#writeTo(OutputStream).
> Here, the input stream is read in a loop using a 4 Kb buffer. Whenever data 
> is received, the received data is pushed to downstream listeners via 
> fireTransferProgress. These listeners (or rather consumers) perform expensive 
> tasks.
> Now, the underlying InputStream implementation used in transfer will return 
> calls to read(buffer, offset, length) as soon as *some* data is available. 
> That is, fireTransferProgress may well be invoked with an average number of 
> bytes less than half the buffer capacity (this varies with the underlying 
> network and hardware architecture). Consequently, fireTransferProgress is 
> invoked *millions of times* for large files. As this is a blocking operation, 
> the time spent in fireTransferProgress dominates and drastically slows down 
> the transfers by at least one order of magnitude. 
> !wagon-issue.png! 
> In our case, we found download speed reduced from a theoretical optimum of 
> ~80 seconds to to more than 3200 seconds.
> From an architectural perspective, I would not want to make the consumers / 
> listeners invoked via fireTransferProgress aware of their potential impact on 
> download speed, but rather refactor the transfer method such that it uses a 
> buffer strategy reducing the the number of fireTransferProgress invocations. 
> This should be done with regard to the expected file size of the transfer, 
> such that fireTransferProgress is invoked often enough but not to frequent.



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

[jira] [Created] (MJAVADOC-543) Archiving to jar is very slow

[Claes Nordmark (JIRA)]

Claes Nordmark created MJAVADOC-543:
---

 Summary: Archiving to jar is very slow
 Key: MJAVADOC-543
 URL: https://issues.apache.org/jira/browse/MJAVADOC-543
 Project: Maven Javadoc Plugin
  Issue Type: Bug
Affects Versions: 3.0.1
 Environment: Redhat7
Reporter: Claes Nordmark


Doing a stackdump while "maven-javadoc-plugin:3.0.1:jar (attach-javadoc)" shows 
thread spending a lot of time in UnixNativeDispatcher.getgrgid.

This was not visible in java 8 and javadoc plugin version 2.4.

Our previous build time has been increased from 5min to 3h 30min.

Tested version Java 11 and 3.0.1 of maven-javadoc-plugin

maven config:


 
{code:java}

org.apache.maven.plugins
maven-javadoc-plugin
3.0.1

  
attach-javadocs

  jar


  false


  
{code}
 

{{java.lang.Thread.State: RUNNABLE}}
{{ at sun.nio.fs.UnixNativeDispatcher.getgrgid(java.base@11/Native Method)}}
{{ at 
sun.nio.fs.UnixUserPrincipals.fromGid(java.base@11/UnixUserPrincipals.java:129)}}
{{ at 
sun.nio.fs.UnixFileAttributes.group(java.base@11/UnixFileAttributes.java:208)}}
{{ - locked <0x0006a2fe0f40> (a sun.nio.fs.UnixFileAttributes)}}
{{ at 
sun.nio.fs.UnixFileAttributeViews$Posix.addRequestedPosixAttributes(java.base@11/UnixFileAttributeViews.java:214)}}
{{ at 
sun.nio.fs.UnixFileAttributeViews$Unix.readAttributes(java.base@11/UnixFileAttributeViews.java:362)}}
{{ at 
sun.nio.fs.AbstractFileSystemProvider.readAttributes(java.base@11/AbstractFileSystemProvider.java:94)}}
{{ at java.nio.file.Files.readAttributes(java.base@11/Files.java:1996)}}
{{ at 
org.codehaus.plexus.components.io.attributes.FileAttributes.(FileAttributes.java:67)}}
{{ at 
org.codehaus.plexus.components.io.resources.PlexusIoFileResourceCollection.addResources(PlexusIoFileResourceCollection.java:156)}}
{{ at 
org.codehaus.plexus.components.io.resources.PlexusIoFileResourceCollection.getResources(PlexusIoFileResourceCollection.java:250)}}
{{ at 
org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:506)}}
{{ at 
org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:257)}}
{{ at 
org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:235)}}
{{ at 
org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:987)}}
{{ at 
org.apache.maven.archiver.MavenArchiver.createArchive(MavenArchiver.java:649)}}
{{ at 
org.apache.maven.plugins.javadoc.JavadocJar.generateArchive(JavadocJar.java:300)}}
{{ at 
org.apache.maven.plugins.javadoc.JavadocJar.doExecute(JavadocJar.java:205)}}
{{ at 
org.apache.maven.plugins.javadoc.AbstractJavadocMojo.execute(AbstractJavadocMojo.java:1912)}}
{{ at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)}}
{{ 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.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:200)}}
{{ at 
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:196)}}
{{ at java.util.concurrent.FutureTask.run(java.base@11/FutureTask.java:264)}}
{{ at 
java.util.concurrent.Executors$RunnableAdapter.call(java.base@11/Executors.java:515)}}
{{ at java.util.concurrent.FutureTask.run(java.base@11/FutureTask.java:264)}}
{{ at 
java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11/ThreadPoolExecutor.java:1128)}}
{{ at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11/ThreadPoolExecutor.java:628)}}
{{ at java.lang.Thread.run(java.base@11/Thread.java:834)}}



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

[jira] [Commented] (SUREFIRE-1593) 3.0.0-M1 produces invalid code sources on Windows

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SUREFIRE-1593:
--

cstamas commented on issue #198: [SUREFIRE-1593] Correcting relativization 
logic to produce valid URIs on Windows
URL: https://github.com/apache/maven-surefire/pull/198#issuecomment-438303029
 
 
   @Tibor17 
   See 
https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#Main_Attributes


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


> 3.0.0-M1 produces invalid code sources on Windows
> -
>
> Key: SUREFIRE-1593
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1593
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: classloading, process forking
>Affects Versions: 3.0.0-M1
>Reporter: Jesse Glick
>Priority: Major
>
> The fix for SUREFIRE-1588 did not work correctly on Windows. (When 
> active—i.e., when the drive letters of the system temporary directory, per 
> SUREFIRE-1400, and the project basedir were the same.) It would produce 
> relative URIs containing {{%5C}} where {{/}} was intended.



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

[jira] [Comment Edited] (MCHECKSTYLE-344) StringIndexOutOfBoundsException in RuleUtil

[JIRA]

[ 
https://issues.apache.org/jira/browse/MCHECKSTYLE-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16685579#comment-16685579
 ] 

Manuel Jesús Recena Soto edited comment on MCHECKSTYLE-344 at 11/13/18 6:31 PM:


(y) I would like to see this fix released.


was (Author: recena):
:+1: I would like to see this fix released.

> StringIndexOutOfBoundsException in RuleUtil
> ---
>
> Key: MCHECKSTYLE-344
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-344
> Project: Maven Checkstyle Plugin
>  Issue Type: Bug
>  Components: checkstyle:check
>Affects Versions: 2.17
>Reporter: fdvxxii
>Assignee: Guillaume Boué
>Priority: Major
> Fix For: 3.0.1
>
>
> {{RuleUtil}} has a bug at line 95:
> {code}
>   final int end = eventSrcName.lastIndexOf('.');
>   eventSrcName = eventSrcName.substring(0, end);  
> {code}
> This code leads to a StringIndexOutOfBoundsException if the variable does not 
> contain a period. I don't know if its a convention to have a period in that 
> string, but either way the error message should me more expressive.



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

[jira] [Comment Edited] (MCHECKSTYLE-344) StringIndexOutOfBoundsException in RuleUtil

[JIRA]

[ 
https://issues.apache.org/jira/browse/MCHECKSTYLE-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16685579#comment-16685579
 ] 

Manuel Jesús Recena Soto edited comment on MCHECKSTYLE-344 at 11/13/18 6:31 PM:


:+1: I would like to see this fix released.


was (Author: recena):
+1 I would like to see this fix released.

> StringIndexOutOfBoundsException in RuleUtil
> ---
>
> Key: MCHECKSTYLE-344
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-344
> Project: Maven Checkstyle Plugin
>  Issue Type: Bug
>  Components: checkstyle:check
>Affects Versions: 2.17
>Reporter: fdvxxii
>Assignee: Guillaume Boué
>Priority: Major
> Fix For: 3.0.1
>
>
> {{RuleUtil}} has a bug at line 95:
> {code}
>   final int end = eventSrcName.lastIndexOf('.');
>   eventSrcName = eventSrcName.substring(0, end);  
> {code}
> This code leads to a StringIndexOutOfBoundsException if the variable does not 
> contain a period. I don't know if its a convention to have a period in that 
> string, but either way the error message should me more expressive.



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

[jira] [Commented] (MCHECKSTYLE-344) StringIndexOutOfBoundsException in RuleUtil

[JIRA]

[ 
https://issues.apache.org/jira/browse/MCHECKSTYLE-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16685579#comment-16685579
 ] 

Manuel Jesús Recena Soto commented on MCHECKSTYLE-344:
--

+1 I would like to see this fix released.

> StringIndexOutOfBoundsException in RuleUtil
> ---
>
> Key: MCHECKSTYLE-344
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-344
> Project: Maven Checkstyle Plugin
>  Issue Type: Bug
>  Components: checkstyle:check
>Affects Versions: 2.17
>Reporter: fdvxxii
>Assignee: Guillaume Boué
>Priority: Major
> Fix For: 3.0.1
>
>
> {{RuleUtil}} has a bug at line 95:
> {code}
>   final int end = eventSrcName.lastIndexOf('.');
>   eventSrcName = eventSrcName.substring(0, end);  
> {code}
> This code leads to a StringIndexOutOfBoundsException if the variable does not 
> contain a period. I don't know if its a convention to have a period in that 
> string, but either way the error message should me more expressive.



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

[jira] [Commented] (MCHECKSTYLE-344) StringIndexOutOfBoundsException in RuleUtil

[Daniel Wegener (JIRA)]

[ 
https://issues.apache.org/jira/browse/MCHECKSTYLE-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16685583#comment-16685583
 ] 

Daniel Wegener commented on MCHECKSTYLE-344:



Hallo,

ich bin bis zum 17.11.2018 im Urlaub und bis dahin leider nicht erreichbar.

Beste Grüße

Daniel Wegener
Holisticon AG

Griegstraße 75, Haus 25
22763 Hamburg
Mobile: +49 176 1616 9025
Office: +49 40 6094 430-0
Fax:  +49 40 6094 430-30
E-Mail: daniel.wege...@holisticon.de
www.holisticon.de

Amtsgericht Hamburg, HRB 107396
Vorstand: Oliver Ihns, Dierk Harbeck
Aufsichtsrat: Sune Nilsson (Vorsitz)


> StringIndexOutOfBoundsException in RuleUtil
> ---
>
> Key: MCHECKSTYLE-344
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-344
> Project: Maven Checkstyle Plugin
>  Issue Type: Bug
>  Components: checkstyle:check
>Affects Versions: 2.17
>Reporter: fdvxxii
>Assignee: Guillaume Boué
>Priority: Major
> Fix For: 3.0.1
>
>
> {{RuleUtil}} has a bug at line 95:
> {code}
>   final int end = eventSrcName.lastIndexOf('.');
>   eventSrcName = eventSrcName.substring(0, end);  
> {code}
> This code leads to a StringIndexOutOfBoundsException if the variable does not 
> contain a period. I don't know if its a convention to have a period in that 
> string, but either way the error message should me more expressive.



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

[jira] [Commented] (MSITE-828) Jdk 1.8 required

[*$^¨%`£]

[ 
https://issues.apache.org/jira/browse/MSITE-828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16685753#comment-16685753
 ] 

Olivier Lamy (*$^¨%`£) commented on MSITE-828:
--

[~oflebbe] no worries I can use the github squash option.

> Jdk 1.8 required
> 
>
> Key: MSITE-828
> URL: https://issues.apache.org/jira/browse/MSITE-828
> Project: Maven Site Plugin
>  Issue Type: Task
>Reporter: Olivier Lamy (*$^¨%`£)
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Major
> Fix For: 3.8
>
>




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

[jira] [Commented] (MJAVADOC-544) Changed behaviour of Javadoc for temporary files encoding (options, argfile, ...)

[Michael Stumpf (JIRA)]

[ 
https://issues.apache.org/jira/browse/MJAVADOC-544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16685826#comment-16685826
 ] 

Michael Stumpf commented on MJAVADOC-544:
-

pull request added: [https://github.com/apache/maven-javadoc-plugin/pull/10]

> Changed behaviour of Javadoc for temporary files encoding (options, argfile, 
> ...)
> -
>
> Key: MJAVADOC-544
> URL: https://issues.apache.org/jira/browse/MJAVADOC-544
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>  Components: javadoc
>Affects Versions: 3.0.1
> Environment: JDK9+, Windows
>Reporter: Michael Stumpf
>Priority: Major
>
> With JDK9 the behaviour of javadoc has apparently changed (at least on 
> Windows platform).
> In a project with special characters (umlaut) in the organization name the 
> content of the options file was written with the default platform encoding 
> (cp1252).
> As a result, the javadoc generation fails on javadoc execution with "Exit 
> code: 1 - javadoc: error - cannot read Input length = 1".
> With JDK8 javadoc generation works.
> It also succeeds with JDK9 and setting the environment variable: 
> JAVA_TOOL_OPTIONS=-Dfile.encoding=UTF-8
> However, this should not be necessary, and maven-javadoc-plugin should work 
> out of the box.
>  
> h6. Cause:
> After some tests it appears to be the case that the JDK9 Javadoc reads 
> @-files always with UTF-8 charset, regardless of platform encoding.
> I looked into the issue and prepared a patch for the plugin when working with 
> JDK9+ and added two tests for the temporary files options and argfile.
> To my knowledge, the temporary file "packages" cannot contain special 
> characters, since this isn't allowed in the java specification, so no 
> workaround is added.
> The file javadoc.bat is not affected (a test with a JDK in the directory 
> "C:\jdk9äöüß" worked with the file being platform encoded).
> h6. 
> Resolution:
> I'll try to create a pull request from 
> https://github.com/michael-st/maven-javadoc-plugin



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

[jira] [Commented] (MSOURCES-119) Archiving to jar is very slow

[Karl Heinz Marbaise (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSOURCES-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16685923#comment-16685923
 ] 

Karl Heinz Marbaise commented on MSOURCES-119:
--

Have you checked with the most recent version of maven-jar-plugin? 3.1.0?

> Archiving to jar is very slow
> -
>
> Key: MSOURCES-119
> URL: https://issues.apache.org/jira/browse/MSOURCES-119
> Project: Maven Source Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0
> Environment: RedHat 7
>Reporter: Claes Nordmark
>Priority: Major
>
> Doing a stackdump while "maven-source-plugin:3.0.0:jar-no-fork 
> (attach-sources)" shows thread spending a lot of time in 
> UnixNativeDispatcher.getgrgid.
> This was not visible in java 8 and source plugin version 2.4.
> Our previous build time has been increased from 5min to 3h 30min.
> Tested version Java 11 and 3.0.0 of maven-source-plugin
> maven config:
> {code:java}
>  
>  org.apache.maven.plugins
>  maven-source-plugin
>  3.0.0
>  
>
>  attach-sources
>  
>jar-no-fork
>  
>
>  
>  {code}
> {{java.lang.Thread.State: RUNNABLE}}
> {{ at sun.nio.fs.UnixNativeDispatcher.getgrgid(java.base@11/Native Method)}}
> {{ at 
> sun.nio.fs.UnixUserPrincipals.fromGid(java.base@11/UnixUserPrincipals.java:129)}}
> {{ at 
> sun.nio.fs.UnixFileAttributes.group(java.base@11/UnixFileAttributes.java:208)}}
> {{ - locked <0x0006b0773fd8> (a sun.nio.fs.UnixFileAttributes)}}
> {{ at 
> sun.nio.fs.UnixFileAttributeViews$Posix.addRequestedPosixAttributes(java.base@11/UnixFileAttributeViews.java:214)}}
> {{ at 
> sun.nio.fs.UnixFileAttributeViews$Unix.readAttributes(java.base@11/UnixFileAttributeViews.java:362)}}
> {{ at 
> sun.nio.fs.AbstractFileSystemProvider.readAttributes(java.base@11/AbstractFileSystemProvider.java:94)}}
> {{ at java.nio.file.Files.readAttributes(java.base@11/Files.java:1996)}}
> {{ at 
> org.codehaus.plexus.components.io.attributes.Java7FileAttributes.(Java7FileAttributes.java:65)}}
> {{ at 
> org.codehaus.plexus.components.io.resources.PlexusIoFileResourceCollection.addResourcesJava7(PlexusIoFileResourceCollection.java:192)}}
> {{ at 
> org.codehaus.plexus.components.io.resources.PlexusIoFileResourceCollection.getResources(PlexusIoFileResourceCollection.java:287)}}
> {{ at 
> org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:504)}}
> {{ at 
> org.apache.maven.plugins.source.AbstractSourceJarMojo.packageSources(AbstractSourceJarMojo.java:287)}}



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

[GitHub] olamy closed pull request #6: Update commons-collections

[GitBox]

olamy closed pull request #6: Update commons-collections
URL: https://github.com/apache/maven-doxia-sitetools/pull/6
 
 
   

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/doxia-site-renderer/pom.xml b/doxia-site-renderer/pom.xml
index 7ee07f1e..037b6a17 100644
--- a/doxia-site-renderer/pom.xml
+++ b/doxia-site-renderer/pom.xml
@@ -132,7 +132,7 @@ under the License.
 
   commons-collections
   commons-collections
-  3.2.1
+  3.2.2
 
 
   org.apache.commons


 


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] (MCOMPILER-306) Incorrect `compilerArgs` example usage

[Hudson (JIRA)]

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

Hudson commented on MCOMPILER-306:
--

Build succeeded in Jenkins: Maven TLP » maven-compiler-plugin » master #78

See 
https://builds.apache.org/job/maven-box/job/maven-compiler-plugin/job/master/78/

> Incorrect `compilerArgs` example usage
> --
>
> Key: MCOMPILER-306
> URL: https://issues.apache.org/jira/browse/MCOMPILER-306
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.6.2
>Reporter: Stephan Schroevers
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Major
> Fix For: 3.8.1
>
>
> The {{compilerArgs}} property documentation 
> [contains|https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#compilerArgs]
>  this example usage:
> {code:xml}
> 
>   -Xmaxerrs=1000
>   -Xlint
>   -J-Duser.language=en_us
> 
> {code}
> But setting {{-Xmaxerrs=1000}} causes:
> {noformat}
>   ...
> Caused by: java.lang.IllegalArgumentException: invalid flag: -Xmaxerrs=1000
>   at com.sun.tools.javac.api.JavacTool.processOptions(JavacTool.java:206)
>   at com.sun.tools.javac.api.JavacTool.getTask(JavacTool.java:156)
>   at com.sun.tools.javac.api.JavacTool.getTask(JavacTool.java:107)
>   at com.sun.tools.javac.api.JavacTool.getTask(JavacTool.java:64)
>   at 
> org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(JavaxToolsCompiler.java:125)
>   ... 16 more
> {noformat}
> This does work:
> {code:xml}
> 
>   -Xmaxerrs
>   1000
> 
> {code}



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

[jira] [Comment Edited] (MJAVADOC-538) JVM "JAVA_TOOL_OPTIONS" or "_JAVA_OPTIONS" message detected as javadoc warning, triggers failure

[Kevin Risden (JIRA)]

[ 
https://issues.apache.org/jira/browse/MJAVADOC-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16685871#comment-16685871
 ] 

Kevin Risden edited comment on MJAVADOC-538 at 11/13/18 11:07 PM:
--

I think the JavadocUtil JavadocOutputStreamConsumer class is only getting 
utilized by JavadocUtil#getJavadocVersion. 
AbstractJavadocMojo#executeJavadocCommandLine creates two 
StringStreamConsumers. It looks like this might be where the issue with the 
warning is not being filtered out.


was (Author: risdenk):
I think the JavadocUtil JavadocOutputStreamConsumer class is only getting 
utilized by JavadocUtil#getJavadocVersion. 
AbstractJavadocMojo#executeJavadocCommandLine creates two 
StringStreamConsumers. It looks like this might be where the issue with the 
warning is not being filtered out. 

 

> JVM "JAVA_TOOL_OPTIONS" or "_JAVA_OPTIONS" message detected as javadoc 
> warning, triggers failure 
> -
>
> Key: MJAVADOC-538
> URL: https://issues.apache.org/jira/browse/MJAVADOC-538
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.1
> Environment: Maven 3.5.4
> Java 1.8.0_181
>Reporter: Yoann Rodière
>Priority: Major
>
> When an environment variable {{_JAVA_OPTIONS}} or {{JAVA_TOOL_OPTIONS}} is 
> defined, every JVM that starts will output a message to inform users of these 
> options being picked up:
> {noformat}
> $ export JAVA_TOOL_OPTIONS=-Dfoo
> $ java -version     
> Picked up JAVA_TOOL_OPTIONS: -Dfoo
> java version "1.8.0_181"
> Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode){noformat}
> Apparently this message cannot be suppressed, that's on purpose an won't 
> change: [https://bugs.openjdk.java.net/browse/JDK-8039152]
>  
> Unfortunately, this message seems to be interpreted by the 
> maven-javadoc-plugin as a warning:
> {noformat}
> [INFO] --- maven-javadoc-plugin:3.0.1:javadoc-no-fork (generate-javadoc) @ 
> hibernate-search-util-internal-common ---
> [INFO] The goal 'org.apache.maven.plugins:maven-javadoc-plugin:3.0.1:javadoc' 
> has not been previously called for the module: 
> 'org.hibernate.search:hibernate-search-util-internal-test:jar:6.0.0-SNAPSHOT'.
>  Trying to invoke it...
> [WARN] Maven will be executed in interactive mode, but no input stream has 
> been configured for this MavenInvoker instance.
> Picked up JAVA_TOOL_OPTIONS: -Dfoo
> [WARNING] Creating fake javadoc directory to prevent repeated invocations: 
> /home/yrodiere/workspaces/main/hibernate-search-parent/util/internal/test/target/site/apidocs
> [ERROR] Error fetching link: 
> /home/yrodiere/workspaces/main/hibernate-search-parent/util/internal/test/target/site/apidocs/package-list.
>  Ignored it.
> [WARNING] Javadoc Warnings
> [WARNING] Picked up JAVA_TOOL_OPTIONS: -Dfoo
> {noformat}
> (see the last line, the message appears in the list of warnings)
> No big deal... until you enable the 
> [failOnWarnings|https://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-no-fork-mojo.html#failOnWarnings]
>  option. Then the whole build will fail just because some JVM detected an 
> environment variable...
> I couldn't find any workaround, except disabling the {{failOnWarnings}} 
> options, but that's more a surrender than a workaround.
> Note that the definition of {{_JAVA_OPTIONS}} or {{JAVA_TOOL_OPTIONS}} is not 
> exactly an exotic use case, especially on Continuous Integration platforms. 
> [Travis CI uses {{_JAVA_OPTIONS}} 
> |https://docs.travis-ci.com/user/build-environment-updates/2017-09-06/#added] 
> to set JVM memory limits in its containerized environments, and [the Jenkins 
> CI Pipeline Maven plugin uses 
> {{JAVA_TOOL_OPTIONS}}|https://wiki.jenkins.io/display/JENKINS/Pipeline+Maven+Plugin#PipelineMavenPlugin-WhydoIseemessages%22[WARNING]PickedupJAVA_TOOL_OPTIONS...%22inthebuildlogs?]
>  to pass options to Maven processes transparently.



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

[jira] [Commented] (SUREFIRE-1541) SurefireBooterForkException: The forked VM terminated without properly saying goodbye. VM crash or System.exit called?

[Tibor Digana (JIRA)]

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

Tibor Digana commented on SUREFIRE-1541:


[~rivanov]
You use Docker or Vagrant or normal host?
If it is normal host then it is not still reproducible but it is another issue.
Do you see the first line [ERROR], can you find the dump files and attach them?
You used another java version as well?

> SurefireBooterForkException: The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?
> --
>
> Key: SUREFIRE-1541
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1541
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.22.0
>Reporter: Anghel Botos
>Assignee: Tibor Digana
>Priority: Major
>
> Attempting to run integration tests using maven-failsafe-plugin with 
> {{-Dmaven.failsafe.debug=false}} yields the following stacktrace:
>  
> {noformat}
> [ERROR] ExecutionException The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?
> [ERROR] Command was cmd.exe /X /C ""C:\Program 
> Files\Java\jdk1.8.0_121\jre\bin\java" false -jar 
> C:\Users\ANGHEL~1.BOT\AppData\Local\Temp\surefire8539836821793811485\surefirebooter6734575521909210279.jar
>  C:\Users\anghel.botos\AppData\Local\Temp\surefire8539836821793811485 
> 2018-07-24T11-18-12_704-jvmRun1 surefire7184511894589995478tmp 
> surefire_411836142070426630764tmp"
> [ERROR] Error occurred in starting fork, check output in log
> [ERROR] Process Exit Code: 1
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.awaitResultsDone(ForkStarter.java:494)
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkPerTestSet(ForkStarter.java:441)
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:293)
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
> {noformat}
>  
> The issue is the "free-floating" {{false}} that appears in the command line 
> used to start a new JVM. I've traced down the issue to 
> {{org.apache.maven.plugin.surefire.AbstractSurefireMojo#getEffectiveDebugForkedProcess}}
>  where the following code can be found:
> {code:java}
> String debugForkedProcess = getDebugForkedProcess();
> if ( "true".equals( debugForkedProcess ) )
> {
> return "-Xdebug -Xnoagent -Djava.compiler=NONE"
> + " 
> -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005";
> }
> return debugForkedProcess;
> {code}
> ...which is quite..."unexpected" to see that one can pass in a value of 
> {{true}}, but not a value of {{false}}.
> Please fix with a proper parsing of true/false values for the 
> {{maven.failsafe.debug}} property.



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

[jira] [Updated] (MCOMPILER-306) Incorrect `compilerArgs` example usage

[*$^¨%`£]

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

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

> Incorrect `compilerArgs` example usage
> --
>
> Key: MCOMPILER-306
> URL: https://issues.apache.org/jira/browse/MCOMPILER-306
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.6.2
>Reporter: Stephan Schroevers
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Major
> Fix For: 3.8.1
>
>
> The {{compilerArgs}} property documentation 
> [contains|https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#compilerArgs]
>  this example usage:
> {code:xml}
> 
>   -Xmaxerrs=1000
>   -Xlint
>   -J-Duser.language=en_us
> 
> {code}
> But setting {{-Xmaxerrs=1000}} causes:
> {noformat}
>   ...
> Caused by: java.lang.IllegalArgumentException: invalid flag: -Xmaxerrs=1000
>   at com.sun.tools.javac.api.JavacTool.processOptions(JavacTool.java:206)
>   at com.sun.tools.javac.api.JavacTool.getTask(JavacTool.java:156)
>   at com.sun.tools.javac.api.JavacTool.getTask(JavacTool.java:107)
>   at com.sun.tools.javac.api.JavacTool.getTask(JavacTool.java:64)
>   at 
> org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(JavaxToolsCompiler.java:125)
>   ... 16 more
> {noformat}
> This does work:
> {code:xml}
> 
>   -Xmaxerrs
>   1000
> 
> {code}



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

[jira] [Commented] (MCOMPILER-306) Incorrect `compilerArgs` example usage

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MCOMPILER-306:
--

olamy closed pull request #9: [MCOMPILER-306] Fix `compilerArgs` example usage
URL: https://github.com/apache/maven-compiler-plugin/pull/9
 
 
   

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/plugin/compiler/AbstractCompilerMojo.java 
b/src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java
index 9295499..d898020 100644
--- a/src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java
+++ b/src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java
@@ -336,7 +336,8 @@
  * Example:
  * 
  * compilerArgs
- *   arg-Xmaxerrs=1000/arg
+ *   arg-Xmaxerrs/arg
+ *   arg1000/arg
  *   arg-Xlint/arg
  *   arg-J-Duser.language=en_us/arg
  * /compilerArgs


 


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


> Incorrect `compilerArgs` example usage
> --
>
> Key: MCOMPILER-306
> URL: https://issues.apache.org/jira/browse/MCOMPILER-306
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.6.2
>Reporter: Stephan Schroevers
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Major
> Fix For: 3.8.1
>
>
> The {{compilerArgs}} property documentation 
> [contains|https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#compilerArgs]
>  this example usage:
> {code:xml}
> 
>   -Xmaxerrs=1000
>   -Xlint
>   -J-Duser.language=en_us
> 
> {code}
> But setting {{-Xmaxerrs=1000}} causes:
> {noformat}
>   ...
> Caused by: java.lang.IllegalArgumentException: invalid flag: -Xmaxerrs=1000
>   at com.sun.tools.javac.api.JavacTool.processOptions(JavacTool.java:206)
>   at com.sun.tools.javac.api.JavacTool.getTask(JavacTool.java:156)
>   at com.sun.tools.javac.api.JavacTool.getTask(JavacTool.java:107)
>   at com.sun.tools.javac.api.JavacTool.getTask(JavacTool.java:64)
>   at 
> org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(JavaxToolsCompiler.java:125)
>   ... 16 more
> {noformat}
> This does work:
> {code:xml}
> 
>   -Xmaxerrs
>   1000
> 
> {code}



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

[jira] [Commented] (MJAVADOC-538) JVM "JAVA_TOOL_OPTIONS" or "_JAVA_OPTIONS" message detected as javadoc warning, triggers failure

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MJAVADOC-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16685879#comment-16685879
 ] 

ASF GitHub Bot commented on MJAVADOC-538:
-

risdenk opened a new pull request #11: [MJAVADOC-538] Filter out 'Picked up'
URL: https://github.com/apache/maven-javadoc-plugin/pull/11
 
 
   


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


> JVM "JAVA_TOOL_OPTIONS" or "_JAVA_OPTIONS" message detected as javadoc 
> warning, triggers failure 
> -
>
> Key: MJAVADOC-538
> URL: https://issues.apache.org/jira/browse/MJAVADOC-538
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.1
> Environment: Maven 3.5.4
> Java 1.8.0_181
>Reporter: Yoann Rodière
>Priority: Major
>
> When an environment variable {{_JAVA_OPTIONS}} or {{JAVA_TOOL_OPTIONS}} is 
> defined, every JVM that starts will output a message to inform users of these 
> options being picked up:
> {noformat}
> $ export JAVA_TOOL_OPTIONS=-Dfoo
> $ java -version     
> Picked up JAVA_TOOL_OPTIONS: -Dfoo
> java version "1.8.0_181"
> Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode){noformat}
> Apparently this message cannot be suppressed, that's on purpose an won't 
> change: [https://bugs.openjdk.java.net/browse/JDK-8039152]
>  
> Unfortunately, this message seems to be interpreted by the 
> maven-javadoc-plugin as a warning:
> {noformat}
> [INFO] --- maven-javadoc-plugin:3.0.1:javadoc-no-fork (generate-javadoc) @ 
> hibernate-search-util-internal-common ---
> [INFO] The goal 'org.apache.maven.plugins:maven-javadoc-plugin:3.0.1:javadoc' 
> has not been previously called for the module: 
> 'org.hibernate.search:hibernate-search-util-internal-test:jar:6.0.0-SNAPSHOT'.
>  Trying to invoke it...
> [WARN] Maven will be executed in interactive mode, but no input stream has 
> been configured for this MavenInvoker instance.
> Picked up JAVA_TOOL_OPTIONS: -Dfoo
> [WARNING] Creating fake javadoc directory to prevent repeated invocations: 
> /home/yrodiere/workspaces/main/hibernate-search-parent/util/internal/test/target/site/apidocs
> [ERROR] Error fetching link: 
> /home/yrodiere/workspaces/main/hibernate-search-parent/util/internal/test/target/site/apidocs/package-list.
>  Ignored it.
> [WARNING] Javadoc Warnings
> [WARNING] Picked up JAVA_TOOL_OPTIONS: -Dfoo
> {noformat}
> (see the last line, the message appears in the list of warnings)
> No big deal... until you enable the 
> [failOnWarnings|https://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-no-fork-mojo.html#failOnWarnings]
>  option. Then the whole build will fail just because some JVM detected an 
> environment variable...
> I couldn't find any workaround, except disabling the {{failOnWarnings}} 
> options, but that's more a surrender than a workaround.
> Note that the definition of {{_JAVA_OPTIONS}} or {{JAVA_TOOL_OPTIONS}} is not 
> exactly an exotic use case, especially on Continuous Integration platforms. 
> [Travis CI uses {{_JAVA_OPTIONS}} 
> |https://docs.travis-ci.com/user/build-environment-updates/2017-09-06/#added] 
> to set JVM memory limits in its containerized environments, and [the Jenkins 
> CI Pipeline Maven plugin uses 
> {{JAVA_TOOL_OPTIONS}}|https://wiki.jenkins.io/display/JENKINS/Pipeline+Maven+Plugin#PipelineMavenPlugin-WhydoIseemessages%22[WARNING]PickedupJAVA_TOOL_OPTIONS...%22inthebuildlogs?]
>  to pass options to Maven processes transparently.



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

[jira] [Commented] (MJAVADOC-538) JVM "JAVA_TOOL_OPTIONS" or "_JAVA_OPTIONS" message detected as javadoc warning, triggers failure

[Kevin Risden (JIRA)]

[ 
https://issues.apache.org/jira/browse/MJAVADOC-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16685880#comment-16685880
 ] 

Kevin Risden commented on MJAVADOC-538:
---

Created a pull request: https://github.com/apache/maven-javadoc-plugin/pull/11

> JVM "JAVA_TOOL_OPTIONS" or "_JAVA_OPTIONS" message detected as javadoc 
> warning, triggers failure 
> -
>
> Key: MJAVADOC-538
> URL: https://issues.apache.org/jira/browse/MJAVADOC-538
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.1
> Environment: Maven 3.5.4
> Java 1.8.0_181
>Reporter: Yoann Rodière
>Priority: Major
>
> When an environment variable {{_JAVA_OPTIONS}} or {{JAVA_TOOL_OPTIONS}} is 
> defined, every JVM that starts will output a message to inform users of these 
> options being picked up:
> {noformat}
> $ export JAVA_TOOL_OPTIONS=-Dfoo
> $ java -version     
> Picked up JAVA_TOOL_OPTIONS: -Dfoo
> java version "1.8.0_181"
> Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode){noformat}
> Apparently this message cannot be suppressed, that's on purpose an won't 
> change: [https://bugs.openjdk.java.net/browse/JDK-8039152]
>  
> Unfortunately, this message seems to be interpreted by the 
> maven-javadoc-plugin as a warning:
> {noformat}
> [INFO] --- maven-javadoc-plugin:3.0.1:javadoc-no-fork (generate-javadoc) @ 
> hibernate-search-util-internal-common ---
> [INFO] The goal 'org.apache.maven.plugins:maven-javadoc-plugin:3.0.1:javadoc' 
> has not been previously called for the module: 
> 'org.hibernate.search:hibernate-search-util-internal-test:jar:6.0.0-SNAPSHOT'.
>  Trying to invoke it...
> [WARN] Maven will be executed in interactive mode, but no input stream has 
> been configured for this MavenInvoker instance.
> Picked up JAVA_TOOL_OPTIONS: -Dfoo
> [WARNING] Creating fake javadoc directory to prevent repeated invocations: 
> /home/yrodiere/workspaces/main/hibernate-search-parent/util/internal/test/target/site/apidocs
> [ERROR] Error fetching link: 
> /home/yrodiere/workspaces/main/hibernate-search-parent/util/internal/test/target/site/apidocs/package-list.
>  Ignored it.
> [WARNING] Javadoc Warnings
> [WARNING] Picked up JAVA_TOOL_OPTIONS: -Dfoo
> {noformat}
> (see the last line, the message appears in the list of warnings)
> No big deal... until you enable the 
> [failOnWarnings|https://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-no-fork-mojo.html#failOnWarnings]
>  option. Then the whole build will fail just because some JVM detected an 
> environment variable...
> I couldn't find any workaround, except disabling the {{failOnWarnings}} 
> options, but that's more a surrender than a workaround.
> Note that the definition of {{_JAVA_OPTIONS}} or {{JAVA_TOOL_OPTIONS}} is not 
> exactly an exotic use case, especially on Continuous Integration platforms. 
> [Travis CI uses {{_JAVA_OPTIONS}} 
> |https://docs.travis-ci.com/user/build-environment-updates/2017-09-06/#added] 
> to set JVM memory limits in its containerized environments, and [the Jenkins 
> CI Pipeline Maven plugin uses 
> {{JAVA_TOOL_OPTIONS}}|https://wiki.jenkins.io/display/JENKINS/Pipeline+Maven+Plugin#PipelineMavenPlugin-WhydoIseemessages%22[WARNING]PickedupJAVA_TOOL_OPTIONS...%22inthebuildlogs?]
>  to pass options to Maven processes transparently.



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

[GitHub] risdenk opened a new pull request #11: [MJAVADOC-538] Filter out 'Picked up'

[GitBox]

risdenk opened a new pull request #11: [MJAVADOC-538] Filter out 'Picked up'
URL: https://github.com/apache/maven-javadoc-plugin/pull/11
 
 
   


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

[GitHub] Tibor17 commented on issue #199: Surefire 1593

[GitBox]

Tibor17 commented on issue #199: Surefire 1593
URL: https://github.com/apache/maven-surefire/pull/199#issuecomment-438499690
 
 
   @jglick 
   Now the tests use TMP and the code is as before, this means Path object is 
created once and the unit test stay as before, just only adopted to Path 
instead of String. All the test pass and your fix is used as intended.


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] (MRESOLVER-63) FileTransformer#transformData(File) should also throw TransformException

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MRESOLVER-63:
-

mcimbora opened a new pull request #23: [MRESOLVER-63] 
FileTransformer#transformData(File) should also throw TransformException
URL: https://github.com/apache/maven-resolver/pull/23
 
 
   Up-for-grabs #DevoxxBE


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


> FileTransformer#transformData(File) should also throw TransformException
> 
>
> Key: MRESOLVER-63
> URL: https://issues.apache.org/jira/browse/MRESOLVER-63
> Project: Maven Resolver
>  Issue Type: Improvement
>  Components: resolver
>Affects Versions: 1.3.1
>Reporter: Robert Scholte
>Priority: Major
>  Labels: up-for-grabs
> Fix For: 1.3.2
>
>
> 1.3.1 introduced the FileTransformer to allow on-the-fly transforming of data.
> For XML files it makes sense to use XMLFilters and create an XMLReader. This 
> can throw a SAXException, which is a checked exception, which shouldn't be 
> rethrown as an IOException.
> Better to introduce a new Exception to handle this case properly.
> Assuming this class isn't used anywhere yet, it should be good to introduce 
> it asap.



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

[GitHub] mcimbora opened a new pull request #23: [MRESOLVER-63] FileTransformer#transformData(File) should also throw TransformException

[GitBox]

mcimbora opened a new pull request #23: [MRESOLVER-63] 
FileTransformer#transformData(File) should also throw TransformException
URL: https://github.com/apache/maven-resolver/pull/23
 
 
   Up-for-grabs #DevoxxBE


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] (MJAVADOC-538) JVM "JAVA_TOOL_OPTIONS" or "_JAVA_OPTIONS" message detected as javadoc warning, triggers failure

[Kevin Risden (JIRA)]

[ 
https://issues.apache.org/jira/browse/MJAVADOC-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16685871#comment-16685871
 ] 

Kevin Risden commented on MJAVADOC-538:
---

I think the JavadocUtil JavadocOutputStreamConsumer class is only getting 
utilized by JavadocUtil#getJavadocVersion. 
AbstractJavadocMojo#executeJavadocCommandLine creates two 
StringStreamConsumers. It looks like this might be where the issue with the 
warning is not being filtered out. 

 

> JVM "JAVA_TOOL_OPTIONS" or "_JAVA_OPTIONS" message detected as javadoc 
> warning, triggers failure 
> -
>
> Key: MJAVADOC-538
> URL: https://issues.apache.org/jira/browse/MJAVADOC-538
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.1
> Environment: Maven 3.5.4
> Java 1.8.0_181
>Reporter: Yoann Rodière
>Priority: Major
>
> When an environment variable {{_JAVA_OPTIONS}} or {{JAVA_TOOL_OPTIONS}} is 
> defined, every JVM that starts will output a message to inform users of these 
> options being picked up:
> {noformat}
> $ export JAVA_TOOL_OPTIONS=-Dfoo
> $ java -version     
> Picked up JAVA_TOOL_OPTIONS: -Dfoo
> java version "1.8.0_181"
> Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode){noformat}
> Apparently this message cannot be suppressed, that's on purpose an won't 
> change: [https://bugs.openjdk.java.net/browse/JDK-8039152]
>  
> Unfortunately, this message seems to be interpreted by the 
> maven-javadoc-plugin as a warning:
> {noformat}
> [INFO] --- maven-javadoc-plugin:3.0.1:javadoc-no-fork (generate-javadoc) @ 
> hibernate-search-util-internal-common ---
> [INFO] The goal 'org.apache.maven.plugins:maven-javadoc-plugin:3.0.1:javadoc' 
> has not been previously called for the module: 
> 'org.hibernate.search:hibernate-search-util-internal-test:jar:6.0.0-SNAPSHOT'.
>  Trying to invoke it...
> [WARN] Maven will be executed in interactive mode, but no input stream has 
> been configured for this MavenInvoker instance.
> Picked up JAVA_TOOL_OPTIONS: -Dfoo
> [WARNING] Creating fake javadoc directory to prevent repeated invocations: 
> /home/yrodiere/workspaces/main/hibernate-search-parent/util/internal/test/target/site/apidocs
> [ERROR] Error fetching link: 
> /home/yrodiere/workspaces/main/hibernate-search-parent/util/internal/test/target/site/apidocs/package-list.
>  Ignored it.
> [WARNING] Javadoc Warnings
> [WARNING] Picked up JAVA_TOOL_OPTIONS: -Dfoo
> {noformat}
> (see the last line, the message appears in the list of warnings)
> No big deal... until you enable the 
> [failOnWarnings|https://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-no-fork-mojo.html#failOnWarnings]
>  option. Then the whole build will fail just because some JVM detected an 
> environment variable...
> I couldn't find any workaround, except disabling the {{failOnWarnings}} 
> options, but that's more a surrender than a workaround.
> Note that the definition of {{_JAVA_OPTIONS}} or {{JAVA_TOOL_OPTIONS}} is not 
> exactly an exotic use case, especially on Continuous Integration platforms. 
> [Travis CI uses {{_JAVA_OPTIONS}} 
> |https://docs.travis-ci.com/user/build-environment-updates/2017-09-06/#added] 
> to set JVM memory limits in its containerized environments, and [the Jenkins 
> CI Pipeline Maven plugin uses 
> {{JAVA_TOOL_OPTIONS}}|https://wiki.jenkins.io/display/JENKINS/Pipeline+Maven+Plugin#PipelineMavenPlugin-WhydoIseemessages%22[WARNING]PickedupJAVA_TOOL_OPTIONS...%22inthebuildlogs?]
>  to pass options to Maven processes transparently.



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

[GitHub] olamy closed pull request #9: [MCOMPILER-306] Fix `compilerArgs` example usage

[GitBox]

olamy closed pull request #9: [MCOMPILER-306] Fix `compilerArgs` example usage
URL: https://github.com/apache/maven-compiler-plugin/pull/9
 
 
   

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/plugin/compiler/AbstractCompilerMojo.java 
b/src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java
index 9295499..d898020 100644
--- a/src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java
+++ b/src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java
@@ -336,7 +336,8 @@
  * Example:
  * 
  * compilerArgs
- *   arg-Xmaxerrs=1000/arg
+ *   arg-Xmaxerrs/arg
+ *   arg1000/arg
  *   arg-Xlint/arg
  *   arg-J-Duser.language=en_us/arg
  * /compilerArgs


 


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] [Assigned] (MCOMPILER-306) Incorrect `compilerArgs` example usage

[*$^¨%`£]

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

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


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

> Incorrect `compilerArgs` example usage
> --
>
> Key: MCOMPILER-306
> URL: https://issues.apache.org/jira/browse/MCOMPILER-306
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.6.2
>Reporter: Stephan Schroevers
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Major
> Fix For: 3.8.1
>
>
> The {{compilerArgs}} property documentation 
> [contains|https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#compilerArgs]
>  this example usage:
> {code:xml}
> 
>   -Xmaxerrs=1000
>   -Xlint
>   -J-Duser.language=en_us
> 
> {code}
> But setting {{-Xmaxerrs=1000}} causes:
> {noformat}
>   ...
> Caused by: java.lang.IllegalArgumentException: invalid flag: -Xmaxerrs=1000
>   at com.sun.tools.javac.api.JavacTool.processOptions(JavacTool.java:206)
>   at com.sun.tools.javac.api.JavacTool.getTask(JavacTool.java:156)
>   at com.sun.tools.javac.api.JavacTool.getTask(JavacTool.java:107)
>   at com.sun.tools.javac.api.JavacTool.getTask(JavacTool.java:64)
>   at 
> org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(JavaxToolsCompiler.java:125)
>   ... 16 more
> {noformat}
> This does work:
> {code:xml}
> 
>   -Xmaxerrs
>   1000
> 
> {code}



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

[jira] [Commented] (MJAVADOC-544) Changed behaviour of Javadoc for temporary files encoding (options, argfile, ...)

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MJAVADOC-544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16685814#comment-16685814
 ] 

ASF GitHub Bot commented on MJAVADOC-544:
-

michael-st opened a new pull request #10: [MJAVADOC-544] - Changed behaviour of 
Javadoc for temporary files encoding (options, argfile, ...)
URL: https://github.com/apache/maven-javadoc-plugin/pull/10
 
 
   mvn -Prun-its verify was run with JDK9 on windows without errors


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


> Changed behaviour of Javadoc for temporary files encoding (options, argfile, 
> ...)
> -
>
> Key: MJAVADOC-544
> URL: https://issues.apache.org/jira/browse/MJAVADOC-544
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>  Components: javadoc
>Affects Versions: 3.0.1
> Environment: JDK9+, Windows
>Reporter: Michael Stumpf
>Priority: Major
>
> With JDK9 the behaviour of javadoc has apparently changed (at least on 
> Windows platform).
> In a project with special characters (umlaut) in the organization name the 
> content of the options file was written with the default platform encoding 
> (cp1252).
> As a result, the javadoc generation fails on javadoc execution with "Exit 
> code: 1 - javadoc: error - cannot read Input length = 1".
> With JDK8 javadoc generation works.
> It also succeeds with JDK9 and setting the environment variable: 
> JAVA_TOOL_OPTIONS=-Dfile.encoding=UTF-8
> However, this should not be necessary, and maven-javadoc-plugin should work 
> out of the box.
>  
> h6. Cause:
> After some tests it appears to be the case that the JDK9 Javadoc reads 
> @-files always with UTF-8 charset, regardless of platform encoding.
> I looked into the issue and prepared a patch for the plugin when working with 
> JDK9+ and added two tests for the temporary files options and argfile.
> To my knowledge, the temporary file "packages" cannot contain special 
> characters, since this isn't allowed in the java specification, so no 
> workaround is added.
> The file javadoc.bat is not affected (a test with a JDK in the directory 
> "C:\jdk9äöüß" worked with the file being platform encoded).
> h6. 
> Resolution:
> I'll try to create a pull request from 
> https://github.com/michael-st/maven-javadoc-plugin



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

[GitHub] michael-st opened a new pull request #10: [MJAVADOC-544] - Changed behaviour of Javadoc for temporary files encoding (options, argfile, ...)

[GitBox]

michael-st opened a new pull request #10: [MJAVADOC-544] - Changed behaviour of 
Javadoc for temporary files encoding (options, argfile, ...)
URL: https://github.com/apache/maven-javadoc-plugin/pull/10
 
 
   mvn -Prun-its verify was run with JDK9 on windows without errors


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] (SUREFIRE-1541) SurefireBooterForkException: The forked VM terminated without properly saying goodbye. VM crash or System.exit called?

[Radoslav Ivanov (JIRA)]

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

Radoslav Ivanov commented on SUREFIRE-1541:
---

This issue is still reproducible on Windows with OpenJDK 11, Maven 3.6.0 and 
SURFIRE plugin 3.0.0-M1
{code:java}
[ERROR] Please refer to dump files (if any exist) [date].dump, 
[date]-jvmRun[N].dump and [date].dumpstream.
[ERROR] The forked VM terminated without properly saying goodbye. VM crash or 
System.exit called?
[ERROR] Command was cmd.exe /X /C "D:\jdk\openjdk-11\bin\java 
-Dformcenter.version=18.11.0 -jar 
C:\Users\dev\AppData\Local\Temp\surefire15361055596163701059\surefirebooter7359148605052433678.jar
 C:\Users\dev\AppData\Local\Temp\surefire15361055596163701059 
2018-11-13T15-01-05_359-jvmRun2 surefire9627993971155929482tmp 
surefire_74224518744146218853tmp"
[ERROR] Error occurred in starting fork, check output in log
[ERROR] Process Exit Code: 1
[ERROR] Crashed tests:
[ERROR] com.avoka.tm.workspace.impl.CategoryApiServiceImplTestCase
[ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: The 
forked VM terminated without properly saying goodbye. VM crash or System.exit 
called?
[ERROR] Command was cmd.exe /X /C "D:\jdk\openjdk-11\bin\java 
-Dformcenter.version=18.11.0 -jar 
C:\Users\dev\AppData\Local\Temp\surefire15361055596163701059\surefirebooter7359148605052433678.jar
 C:\Users\dev\AppData\Local\Temp\surefire15361055596163701059 
2018-11-13T15-01-05_359-jvmRun2 surefire9627993971155929482tmp 
surefire_74224518744146218853tmp"
[ERROR] Error occurred in starting fork, check output in log
[ERROR] Process Exit Code: 1
[ERROR] Crashed tests:
{code}
Any suggestions on how to solve it would be much appreciated.

> SurefireBooterForkException: The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?
> --
>
> Key: SUREFIRE-1541
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1541
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.22.0
>Reporter: Anghel Botos
>Assignee: Tibor Digana
>Priority: Major
>
> Attempting to run integration tests using maven-failsafe-plugin with 
> {{-Dmaven.failsafe.debug=false}} yields the following stacktrace:
>  
> {noformat}
> [ERROR] ExecutionException The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?
> [ERROR] Command was cmd.exe /X /C ""C:\Program 
> Files\Java\jdk1.8.0_121\jre\bin\java" false -jar 
> C:\Users\ANGHEL~1.BOT\AppData\Local\Temp\surefire8539836821793811485\surefirebooter6734575521909210279.jar
>  C:\Users\anghel.botos\AppData\Local\Temp\surefire8539836821793811485 
> 2018-07-24T11-18-12_704-jvmRun1 surefire7184511894589995478tmp 
> surefire_411836142070426630764tmp"
> [ERROR] Error occurred in starting fork, check output in log
> [ERROR] Process Exit Code: 1
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.awaitResultsDone(ForkStarter.java:494)
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkPerTestSet(ForkStarter.java:441)
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:293)
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
> {noformat}
>  
> The issue is the "free-floating" {{false}} that appears in the command line 
> used to start a new JVM. I've traced down the issue to 
> {{org.apache.maven.plugin.surefire.AbstractSurefireMojo#getEffectiveDebugForkedProcess}}
>  where the following code can be found:
> {code:java}
> String debugForkedProcess = getDebugForkedProcess();
> if ( "true".equals( debugForkedProcess ) )
> {
> return "-Xdebug -Xnoagent -Djava.compiler=NONE"
> + " 
> -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005";
> }
> return debugForkedProcess;
> {code}
> ...which is quite..."unexpected" to see that one can pass in a value of 
> {{true}}, but not a value of {{false}}.
> Please fix with a proper parsing of true/false values for the 
> {{maven.failsafe.debug}} property.



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

[jira] [Closed] (MCOMPILER-306) Incorrect `compilerArgs` example usage

[*$^¨%`£]

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

Olivier Lamy (*$^¨%`£) closed MCOMPILER-306.

Resolution: Fixed

pr merged . Thanks for your contribution!

> Incorrect `compilerArgs` example usage
> --
>
> Key: MCOMPILER-306
> URL: https://issues.apache.org/jira/browse/MCOMPILER-306
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.6.2
>Reporter: Stephan Schroevers
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Major
> Fix For: 3.8.1
>
>
> The {{compilerArgs}} property documentation 
> [contains|https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#compilerArgs]
>  this example usage:
> {code:xml}
> 
>   -Xmaxerrs=1000
>   -Xlint
>   -J-Duser.language=en_us
> 
> {code}
> But setting {{-Xmaxerrs=1000}} causes:
> {noformat}
>   ...
> Caused by: java.lang.IllegalArgumentException: invalid flag: -Xmaxerrs=1000
>   at com.sun.tools.javac.api.JavacTool.processOptions(JavacTool.java:206)
>   at com.sun.tools.javac.api.JavacTool.getTask(JavacTool.java:156)
>   at com.sun.tools.javac.api.JavacTool.getTask(JavacTool.java:107)
>   at com.sun.tools.javac.api.JavacTool.getTask(JavacTool.java:64)
>   at 
> org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(JavaxToolsCompiler.java:125)
>   ... 16 more
> {noformat}
> This does work:
> {code:xml}
> 
>   -Xmaxerrs
>   1000
> 
> {code}



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

[jira] [Created] (MJAVADOC-544) Changed behaviour of Javadoc for temporary files encoding (options, argfile, ...)

[Michael Stumpf (JIRA)]

Michael Stumpf created MJAVADOC-544:
---

 Summary: Changed behaviour of Javadoc for temporary files encoding 
(options, argfile, ...)
 Key: MJAVADOC-544
 URL: https://issues.apache.org/jira/browse/MJAVADOC-544
 Project: Maven Javadoc Plugin
  Issue Type: Bug
  Components: javadoc
Affects Versions: 3.0.1
 Environment: JDK9+, Windows
Reporter: Michael Stumpf


With JDK9 the behaviour of javadoc has apparently changed (at least on Windows 
platform).


In a project with special characters (umlaut) in the organization name the 
content of the options file was written with the default platform encoding 
(cp1252).

As a result, the javadoc generation fails on javadoc execution with "Exit code: 
1 - javadoc: error - cannot read Input length = 1".


With JDK8 javadoc generation works.

It also succeeds with JDK9 and setting the environment variable: 
JAVA_TOOL_OPTIONS=-Dfile.encoding=UTF-8

However, this should not be necessary, and maven-javadoc-plugin should work out 
of the box.

 
h6. Cause:

After some tests it appears to be the case that the JDK9 Javadoc reads @-files 
always with UTF-8 charset, regardless of platform encoding.


I looked into the issue and prepared a patch for the plugin when working with 
JDK9+ and added two tests for the temporary files options and argfile.

To my knowledge, the temporary file "packages" cannot contain special 
characters, since this isn't allowed in the java specification, so no 
workaround is added.

The file javadoc.bat is not affected (a test with a JDK in the directory 
"C:\jdk9äöüß" worked with the file being platform encoded).
h6. 
Resolution:

I'll try to create a pull request from 
https://github.com/michael-st/maven-javadoc-plugin



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

[jira] [Commented] (MENFORCER-319) UTF-8 BOM in pom.xml breaks banDuplicatePomDependencyVersions rule

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MENFORCER-319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16685919#comment-16685919
 ] 

ASF GitHub Bot commented on MENFORCER-319:
--

khmarbaise commented on issue #45: [MENFORCER-319] Handle UTF-8 BOM when 
parsing pom.xml files
URL: https://github.com/apache/maven-enforcer/pull/45#issuecomment-438485075
 
 
   The patch looks good so far but unfortunately I don't see a test case for 
that..


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


> UTF-8 BOM in pom.xml breaks banDuplicatePomDependencyVersions rule
> --
>
> Key: MENFORCER-319
> URL: https://issues.apache.org/jira/browse/MENFORCER-319
> Project: Maven Enforcer Plugin
>  Issue Type: Bug
>  Components: Standard Rules
>Affects Versions: 3.0.0-M2
>Reporter: Václav Haisman
>Priority: Major
> Attachments: 
> Handle_parsing_of_pom_xml_in_BanDuplicatePomDependencyVersions_java_similarly_to_how_actua.patch,
>  pom.xml
>
>
> Having UTF-8 BOM at the beginning of {{pom.xml}} causes the 
> banDuplicatePomDependencyVersions rule to fail to parse the file with the 
> following exception being shown by {{-X}} output:
> {noformat}
> [DEBUG] Adding failure due to exception
> org.apache.maven.enforcer.rule.api.EnforcerRuleException: Unable to retrieve 
> the MavenProject:
> at 
> org.apache.maven.plugins.enforcer.BanDuplicatePomDependencyVersions.execute 
> (BanDuplicatePomDependencyVersions.java:87)
> at org.apache.maven.plugins.enforcer.EnforceMojo.execute 
> (EnforceMojo.java:194)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
> (DefaultBuildPluginManager.java:137)
> 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:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:954)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (Unknown Source)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (Unknown 
> Source)
> at java.lang.reflect.Method.invoke (Unknown Source)
> 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.codehaus.plexus.util.xml.pull.XmlPullParserException: only 
> whitespace content allowed before start tag and not \uef (position: 
> START_DOCUMENT seen \uef... @1:1)
> at org.codehaus.plexus.util.xml.pull.MXParser.parseProlog 
> (MXParser.java:1862)
> at org.codehaus.plexus.util.xml.pull.MXParser.nextImpl 
> (MXParser.java:1698)
> at org.codehaus.plexus.util.xml.pull.MXParser.next (MXParser.java:1317)
> at org.apache.maven.model.io.xpp3.MavenXpp3Reader.read 
> (MavenXpp3Reader.java:3856)
> at org.apache.maven.model.io.xpp3.MavenXpp3Reader.read 
> (MavenXpp3Reader.java:595)
> at org.apache.maven.model.io.xpp3.MavenXpp3Reader.read 
> (MavenXpp3Reader.java:609)
> at 
> org.apache.maven.plugins.enforcer.BanDuplicatePomDependencyVersions.execute 
> (BanDuplicatePomDependencyVersions.java:75)
> at org.apache.maven.plugins.enforcer.EnforceMojo.execute 
> (EnforceMojo.java:194)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
> (DefaultBuildPluginManager.java:137)

[GitHub] khmarbaise commented on issue #45: [MENFORCER-319] Handle UTF-8 BOM when parsing pom.xml files

[GitBox]

khmarbaise commented on issue #45: [MENFORCER-319] Handle UTF-8 BOM when 
parsing pom.xml files
URL: https://github.com/apache/maven-enforcer/pull/45#issuecomment-438485075
 
 
   The patch looks good so far but unfortunately I don't see a test case for 
that..


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] (MSOURCES-119) Archiving to jar is very slow

[Claes Nordmark (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSOURCES-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686132#comment-16686132
 ] 

Claes Nordmark commented on MSOURCES-119:
-

Yes, tested it now and its the same behavior :( 

> Archiving to jar is very slow
> -
>
> Key: MSOURCES-119
> URL: https://issues.apache.org/jira/browse/MSOURCES-119
> Project: Maven Source Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0
> Environment: RedHat 7
>Reporter: Claes Nordmark
>Priority: Major
>
> Doing a stackdump while "maven-source-plugin:3.0.0:jar-no-fork 
> (attach-sources)" shows thread spending a lot of time in 
> UnixNativeDispatcher.getgrgid.
> This was not visible in java 8 and source plugin version 2.4.
> Our previous build time has been increased from 5min to 3h 30min.
> Tested version Java 11 and 3.0.0 of maven-source-plugin
> maven config:
> {code:java}
>  
>  org.apache.maven.plugins
>  maven-source-plugin
>  3.0.0
>  
>
>  attach-sources
>  
>jar-no-fork
>  
>
>  
>  {code}
> {{java.lang.Thread.State: RUNNABLE}}
> {{ at sun.nio.fs.UnixNativeDispatcher.getgrgid(java.base@11/Native Method)}}
> {{ at 
> sun.nio.fs.UnixUserPrincipals.fromGid(java.base@11/UnixUserPrincipals.java:129)}}
> {{ at 
> sun.nio.fs.UnixFileAttributes.group(java.base@11/UnixFileAttributes.java:208)}}
> {{ - locked <0x0006b0773fd8> (a sun.nio.fs.UnixFileAttributes)}}
> {{ at 
> sun.nio.fs.UnixFileAttributeViews$Posix.addRequestedPosixAttributes(java.base@11/UnixFileAttributeViews.java:214)}}
> {{ at 
> sun.nio.fs.UnixFileAttributeViews$Unix.readAttributes(java.base@11/UnixFileAttributeViews.java:362)}}
> {{ at 
> sun.nio.fs.AbstractFileSystemProvider.readAttributes(java.base@11/AbstractFileSystemProvider.java:94)}}
> {{ at java.nio.file.Files.readAttributes(java.base@11/Files.java:1996)}}
> {{ at 
> org.codehaus.plexus.components.io.attributes.Java7FileAttributes.(Java7FileAttributes.java:65)}}
> {{ at 
> org.codehaus.plexus.components.io.resources.PlexusIoFileResourceCollection.addResourcesJava7(PlexusIoFileResourceCollection.java:192)}}
> {{ at 
> org.codehaus.plexus.components.io.resources.PlexusIoFileResourceCollection.getResources(PlexusIoFileResourceCollection.java:287)}}
> {{ at 
> org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:504)}}
> {{ at 
> org.apache.maven.plugins.source.AbstractSourceJarMojo.packageSources(AbstractSourceJarMojo.java:287)}}



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

[jira] [Closed] (SUREFIRE-1595) Java 1.7 feature System.lineSeparator()

[Tibor Digana (JIRA)]

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

Tibor Digana closed SUREFIRE-1595.
--
Resolution: Fixed

https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=aa2f0387341e5024eea590fe616fda85ab25b132

> Java 1.7 feature System.lineSeparator()
> ---
>
> Key: SUREFIRE-1595
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1595
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M2
>
>
> Used in a place of {{System.getProperty( "line.separator" )}}.



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

[jira] [Closed] (SUREFIRE-1596) Unnecessary check JAVA_RECENT == JAVA_1_7 in unit tests

[Tibor Digana (JIRA)]

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

Tibor Digana closed SUREFIRE-1596.
--
Resolution: Fixed

https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=b9ad0cfe7822ee9b1ec1b98e3a768f0dd566a2e4

> Unnecessary check JAVA_RECENT == JAVA_1_7 in unit tests
> ---
>
> Key: SUREFIRE-1596
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1596
> Project: Maven Surefire
>  Issue Type: Test
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M2
>
>
> Not needed in unit tests, e.g.:
> {code:java}
> @BeforeClass
> public static void withJava7Plus()
> {
> assumeTrue( JAVA_RECENT.atLeast( JAVA_1_7 ) );
> }
> {code}



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

[jira] [Closed] (SUREFIRE-1597) ModularClasspathForkConfiguration with debug logs (@args file and its path on file system)

[Tibor Digana (JIRA)]

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

Tibor Digana closed SUREFIRE-1597.
--
Resolution: Fixed

https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=85105161f413f9cfa160a4a86c6d6a5926c0d6f9

> ModularClasspathForkConfiguration with debug logs (@args file and its path on 
> file system)
> --
>
> Key: SUREFIRE-1597
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1597
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M2
>
>
> Added debug logs (@args file and its path on file system).



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

[jira] [Closed] (SUREFIRE-1594) Java 1.7 feature try-catch - multiple exceptions in one catch

[Tibor Digana (JIRA)]

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

Tibor Digana closed SUREFIRE-1594.
--
Resolution: Fixed

https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=0e212dbab652bb9fc795c5a281519d8aec55a674

> Java 1.7 feature try-catch - multiple exceptions in one catch
> -
>
> Key: SUREFIRE-1594
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1594
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M2
>
>
> The last occurrence was not changed to Java 1.7 style in 
> {{SurefireDependencyResolver}} after the version {{3.0.0-M1}}.



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

[GitHub] yrodiere commented on issue #11: [MJAVADOC-538] Filter out 'Picked up'

[GitBox]

yrodiere commented on issue #11: [MJAVADOC-538] Filter out 'Picked up'
URL: 
https://github.com/apache/maven-javadoc-plugin/pull/11#issuecomment-438566431
 
 
   FWIW, I can confirm this solves the problem in my project. Thanks!


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] (MJAVADOC-538) JVM "JAVA_TOOL_OPTIONS" or "_JAVA_OPTIONS" message detected as javadoc warning, triggers failure

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MJAVADOC-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686166#comment-16686166
 ] 

ASF GitHub Bot commented on MJAVADOC-538:
-

yrodiere commented on issue #11: [MJAVADOC-538] Filter out 'Picked up'
URL: 
https://github.com/apache/maven-javadoc-plugin/pull/11#issuecomment-438566431
 
 
   FWIW, I can confirm this solves the problem in my project. Thanks!


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


> JVM "JAVA_TOOL_OPTIONS" or "_JAVA_OPTIONS" message detected as javadoc 
> warning, triggers failure 
> -
>
> Key: MJAVADOC-538
> URL: https://issues.apache.org/jira/browse/MJAVADOC-538
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.1
> Environment: Maven 3.5.4
> Java 1.8.0_181
>Reporter: Yoann Rodière
>Priority: Major
>
> When an environment variable {{_JAVA_OPTIONS}} or {{JAVA_TOOL_OPTIONS}} is 
> defined, every JVM that starts will output a message to inform users of these 
> options being picked up:
> {noformat}
> $ export JAVA_TOOL_OPTIONS=-Dfoo
> $ java -version     
> Picked up JAVA_TOOL_OPTIONS: -Dfoo
> java version "1.8.0_181"
> Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode){noformat}
> Apparently this message cannot be suppressed, that's on purpose an won't 
> change: [https://bugs.openjdk.java.net/browse/JDK-8039152]
>  
> Unfortunately, this message seems to be interpreted by the 
> maven-javadoc-plugin as a warning:
> {noformat}
> [INFO] --- maven-javadoc-plugin:3.0.1:javadoc-no-fork (generate-javadoc) @ 
> hibernate-search-util-internal-common ---
> [INFO] The goal 'org.apache.maven.plugins:maven-javadoc-plugin:3.0.1:javadoc' 
> has not been previously called for the module: 
> 'org.hibernate.search:hibernate-search-util-internal-test:jar:6.0.0-SNAPSHOT'.
>  Trying to invoke it...
> [WARN] Maven will be executed in interactive mode, but no input stream has 
> been configured for this MavenInvoker instance.
> Picked up JAVA_TOOL_OPTIONS: -Dfoo
> [WARNING] Creating fake javadoc directory to prevent repeated invocations: 
> /home/yrodiere/workspaces/main/hibernate-search-parent/util/internal/test/target/site/apidocs
> [ERROR] Error fetching link: 
> /home/yrodiere/workspaces/main/hibernate-search-parent/util/internal/test/target/site/apidocs/package-list.
>  Ignored it.
> [WARNING] Javadoc Warnings
> [WARNING] Picked up JAVA_TOOL_OPTIONS: -Dfoo
> {noformat}
> (see the last line, the message appears in the list of warnings)
> No big deal... until you enable the 
> [failOnWarnings|https://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-no-fork-mojo.html#failOnWarnings]
>  option. Then the whole build will fail just because some JVM detected an 
> environment variable...
> I couldn't find any workaround, except disabling the {{failOnWarnings}} 
> options, but that's more a surrender than a workaround.
> Note that the definition of {{_JAVA_OPTIONS}} or {{JAVA_TOOL_OPTIONS}} is not 
> exactly an exotic use case, especially on Continuous Integration platforms. 
> [Travis CI uses {{_JAVA_OPTIONS}} 
> |https://docs.travis-ci.com/user/build-environment-updates/2017-09-06/#added] 
> to set JVM memory limits in its containerized environments, and [the Jenkins 
> CI Pipeline Maven plugin uses 
> {{JAVA_TOOL_OPTIONS}}|https://wiki.jenkins.io/display/JENKINS/Pipeline+Maven+Plugin#PipelineMavenPlugin-WhydoIseemessages%22[WARNING]PickedupJAVA_TOOL_OPTIONS...%22inthebuildlogs?]
>  to pass options to Maven processes transparently.



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

[jira] [Comment Edited] (SUREFIRE-1541) SurefireBooterForkException: The forked VM terminated without properly saying goodbye. VM crash or System.exit called?

[Radoslav Ivanov (JIRA)]

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

Radoslav Ivanov edited comment on SUREFIRE-1541 at 11/14/18 3:46 AM:
-

Should we change the default memory settings - note the 
attached.[^hs_err_pid3584.log]


was (Author: rivanov):
Should we change the memory settings - note the attached.[^hs_err_pid3584.log]

> SurefireBooterForkException: The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?
> --
>
> Key: SUREFIRE-1541
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1541
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.22.0
>Reporter: Anghel Botos
>Assignee: Tibor Digana
>Priority: Major
> Attachments: hs_err_pid3584.log
>
>
> Attempting to run integration tests using maven-failsafe-plugin with 
> {{-Dmaven.failsafe.debug=false}} yields the following stacktrace:
>  
> {noformat}
> [ERROR] ExecutionException The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?
> [ERROR] Command was cmd.exe /X /C ""C:\Program 
> Files\Java\jdk1.8.0_121\jre\bin\java" false -jar 
> C:\Users\ANGHEL~1.BOT\AppData\Local\Temp\surefire8539836821793811485\surefirebooter6734575521909210279.jar
>  C:\Users\anghel.botos\AppData\Local\Temp\surefire8539836821793811485 
> 2018-07-24T11-18-12_704-jvmRun1 surefire7184511894589995478tmp 
> surefire_411836142070426630764tmp"
> [ERROR] Error occurred in starting fork, check output in log
> [ERROR] Process Exit Code: 1
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.awaitResultsDone(ForkStarter.java:494)
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkPerTestSet(ForkStarter.java:441)
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:293)
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
> {noformat}
>  
> The issue is the "free-floating" {{false}} that appears in the command line 
> used to start a new JVM. I've traced down the issue to 
> {{org.apache.maven.plugin.surefire.AbstractSurefireMojo#getEffectiveDebugForkedProcess}}
>  where the following code can be found:
> {code:java}
> String debugForkedProcess = getDebugForkedProcess();
> if ( "true".equals( debugForkedProcess ) )
> {
> return "-Xdebug -Xnoagent -Djava.compiler=NONE"
> + " 
> -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005";
> }
> return debugForkedProcess;
> {code}
> ...which is quite..."unexpected" to see that one can pass in a value of 
> {{true}}, but not a value of {{false}}.
> Please fix with a proper parsing of true/false values for the 
> {{maven.failsafe.debug}} property.



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

[jira] [Commented] (SUREFIRE-1541) SurefireBooterForkException: The forked VM terminated without properly saying goodbye. VM crash or System.exit called?

[Radoslav Ivanov (JIRA)]

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

Radoslav Ivanov commented on SUREFIRE-1541:
---

Should we change the memory settings - note the attached.[^hs_err_pid3584.log]

> SurefireBooterForkException: The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?
> --
>
> Key: SUREFIRE-1541
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1541
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.22.0
>Reporter: Anghel Botos
>Assignee: Tibor Digana
>Priority: Major
> Attachments: hs_err_pid3584.log
>
>
> Attempting to run integration tests using maven-failsafe-plugin with 
> {{-Dmaven.failsafe.debug=false}} yields the following stacktrace:
>  
> {noformat}
> [ERROR] ExecutionException The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?
> [ERROR] Command was cmd.exe /X /C ""C:\Program 
> Files\Java\jdk1.8.0_121\jre\bin\java" false -jar 
> C:\Users\ANGHEL~1.BOT\AppData\Local\Temp\surefire8539836821793811485\surefirebooter6734575521909210279.jar
>  C:\Users\anghel.botos\AppData\Local\Temp\surefire8539836821793811485 
> 2018-07-24T11-18-12_704-jvmRun1 surefire7184511894589995478tmp 
> surefire_411836142070426630764tmp"
> [ERROR] Error occurred in starting fork, check output in log
> [ERROR] Process Exit Code: 1
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.awaitResultsDone(ForkStarter.java:494)
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkPerTestSet(ForkStarter.java:441)
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:293)
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
> {noformat}
>  
> The issue is the "free-floating" {{false}} that appears in the command line 
> used to start a new JVM. I've traced down the issue to 
> {{org.apache.maven.plugin.surefire.AbstractSurefireMojo#getEffectiveDebugForkedProcess}}
>  where the following code can be found:
> {code:java}
> String debugForkedProcess = getDebugForkedProcess();
> if ( "true".equals( debugForkedProcess ) )
> {
> return "-Xdebug -Xnoagent -Djava.compiler=NONE"
> + " 
> -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005";
> }
> return debugForkedProcess;
> {code}
> ...which is quite..."unexpected" to see that one can pass in a value of 
> {{true}}, but not a value of {{false}}.
> Please fix with a proper parsing of true/false values for the 
> {{maven.failsafe.debug}} property.



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

[jira] [Closed] (SUREFIRE-1591) Java 1.7 feature Diamonds replaced Generics

[Tibor Digana (JIRA)]

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

Tibor Digana closed SUREFIRE-1591.
--
Resolution: Fixed

https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=5dcd98482c4ac599d0a053ddbe35ed18a70e62b4

> Java 1.7 feature Diamonds replaced Generics
> ---
>
> Key: SUREFIRE-1591
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1591
> Project: Maven Surefire
>  Issue Type: Improvement
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M2
>
>
> Java 1.7 does not require specifying Generics in constructor for  variable 
> assignment.
> {code:java}
> Map> mergedTestHistoryResult = new 
> HashMap>();
> {code}
> turns to in Java 1.7:
> {code:java}
> Map> mergedTestHistoryResult = new HashMap<>();
> {code}



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

[jira] [Closed] (SUREFIRE-1598) Fixed typo in assertion statement in integration test Surefire855AllowFailsafeUseArtifactFileIT

[Tibor Digana (JIRA)]

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

Tibor Digana closed SUREFIRE-1598.
--
Resolution: Fixed

https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=e810bd8ba2b4e4e8e6843da5b770bd8476d26e3c

> Fixed typo in assertion statement in integration test 
> Surefire855AllowFailsafeUseArtifactFileIT
> ---
>
> Key: SUREFIRE-1598
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1598
> Project: Maven Surefire
>  Issue Type: Test
>Affects Versions: 3.0.0-M1
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M2
>
>




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

[jira] [Comment Edited] (SUREFIRE-1541) SurefireBooterForkException: The forked VM terminated without properly saying goodbye. VM crash or System.exit called?

[Radoslav Ivanov (JIRA)]

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

Radoslav Ivanov edited comment on SUREFIRE-1541 at 11/14/18 2:52 AM:
-

This issue is still reproducible on Windows with OpenJDK 11, Maven 3.6.0 and 
SURFIRE plugin 3.0.0-M1
{code:java}
[ERROR] Please refer to dump files (if any exist) [date].dump, 
[date]-jvmRun[N].dump and [date].dumpstream.
[ERROR] The forked VM terminated without properly saying goodbye. VM crash or 
System.exit called?
[ERROR] Command was cmd.exe /X /C "D:\jdk\openjdk-11\bin\java 
-Dformcenter.version=18.11.0 -jar 
C:\Users\dev\AppData\Local\Temp\surefire15361055596163701059\surefirebooter7359148605052433678.jar
 C:\Users\dev\AppData\Local\Temp\surefire15361055596163701059 
2018-11-13T15-01-05_359-jvmRun2 surefire9627993971155929482tmp 
surefire_74224518744146218853tmp"
[ERROR] Error occurred in starting fork, check output in log
[ERROR] Process Exit Code: 1
[ERROR] Crashed tests:
[ERROR] ...TestCase
[ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: The 
forked VM terminated without properly saying goodbye. VM crash or System.exit 
called?
[ERROR] Command was cmd.exe /X /C "D:\jdk\openjdk-11\bin\java 
-Dformcenter.version=18.11.0 -jar 
C:\Users\dev\AppData\Local\Temp\surefire15361055596163701059\surefirebooter7359148605052433678.jar
 C:\Users\dev\AppData\Local\Temp\surefire15361055596163701059 
2018-11-13T15-01-05_359-jvmRun2 surefire9627993971155929482tmp 
surefire_74224518744146218853tmp"
[ERROR] Error occurred in starting fork, check output in log
[ERROR] Process Exit Code: 1
[ERROR] Crashed tests:
{code}
Any suggestions on how to solve it would be much appreciated.


was (Author: rivanov):
This issue is still reproducible on Windows with OpenJDK 11, Maven 3.6.0 and 
SURFIRE plugin 3.0.0-M1
{code:java}
[ERROR] Please refer to dump files (if any exist) [date].dump, 
[date]-jvmRun[N].dump and [date].dumpstream.
[ERROR] The forked VM terminated without properly saying goodbye. VM crash or 
System.exit called?
[ERROR] Command was cmd.exe /X /C "D:\jdk\openjdk-11\bin\java 
-Dformcenter.version=18.11.0 -jar 
C:\Users\dev\AppData\Local\Temp\surefire15361055596163701059\surefirebooter7359148605052433678.jar
 C:\Users\dev\AppData\Local\Temp\surefire15361055596163701059 
2018-11-13T15-01-05_359-jvmRun2 surefire9627993971155929482tmp 
surefire_74224518744146218853tmp"
[ERROR] Error occurred in starting fork, check output in log
[ERROR] Process Exit Code: 1
[ERROR] Crashed tests:
[ERROR] com.avoka.tm.workspace.impl.CategoryApiServiceImplTestCase
[ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: The 
forked VM terminated without properly saying goodbye. VM crash or System.exit 
called?
[ERROR] Command was cmd.exe /X /C "D:\jdk\openjdk-11\bin\java 
-Dformcenter.version=18.11.0 -jar 
C:\Users\dev\AppData\Local\Temp\surefire15361055596163701059\surefirebooter7359148605052433678.jar
 C:\Users\dev\AppData\Local\Temp\surefire15361055596163701059 
2018-11-13T15-01-05_359-jvmRun2 surefire9627993971155929482tmp 
surefire_74224518744146218853tmp"
[ERROR] Error occurred in starting fork, check output in log
[ERROR] Process Exit Code: 1
[ERROR] Crashed tests:
{code}
Any suggestions on how to solve it would be much appreciated.

> SurefireBooterForkException: The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?
> --
>
> Key: SUREFIRE-1541
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1541
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.22.0
>Reporter: Anghel Botos
>Assignee: Tibor Digana
>Priority: Major
>
> Attempting to run integration tests using maven-failsafe-plugin with 
> {{-Dmaven.failsafe.debug=false}} yields the following stacktrace:
>  
> {noformat}
> [ERROR] ExecutionException The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?
> [ERROR] Command was cmd.exe /X /C ""C:\Program 
> Files\Java\jdk1.8.0_121\jre\bin\java" false -jar 
> C:\Users\ANGHEL~1.BOT\AppData\Local\Temp\surefire8539836821793811485\surefirebooter6734575521909210279.jar
>  C:\Users\anghel.botos\AppData\Local\Temp\surefire8539836821793811485 
> 2018-07-24T11-18-12_704-jvmRun1 surefire7184511894589995478tmp 
> surefire_411836142070426630764tmp"
> [ERROR] Error occurred in starting fork, check output in log
> [ERROR] Process Exit Code: 1
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.awaitResultsDone(ForkStarter.java:494)
> [ERROR] at 
> 

[jira] [Commented] (SUREFIRE-1541) SurefireBooterForkException: The forked VM terminated without properly saying goodbye. VM crash or System.exit called?

[Tibor Digana (JIRA)]

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

Tibor Digana commented on SUREFIRE-1541:


[~rivanov]
As I said, this is another reason of the fault. You have got an Out of Memory 
Error. {{The system is out of physical RAM or swap space}}.

> SurefireBooterForkException: The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?
> --
>
> Key: SUREFIRE-1541
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1541
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.22.0
>Reporter: Anghel Botos
>Assignee: Tibor Digana
>Priority: Major
> Attachments: hs_err_pid3584.log
>
>
> Attempting to run integration tests using maven-failsafe-plugin with 
> {{-Dmaven.failsafe.debug=false}} yields the following stacktrace:
>  
> {noformat}
> [ERROR] ExecutionException The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?
> [ERROR] Command was cmd.exe /X /C ""C:\Program 
> Files\Java\jdk1.8.0_121\jre\bin\java" false -jar 
> C:\Users\ANGHEL~1.BOT\AppData\Local\Temp\surefire8539836821793811485\surefirebooter6734575521909210279.jar
>  C:\Users\anghel.botos\AppData\Local\Temp\surefire8539836821793811485 
> 2018-07-24T11-18-12_704-jvmRun1 surefire7184511894589995478tmp 
> surefire_411836142070426630764tmp"
> [ERROR] Error occurred in starting fork, check output in log
> [ERROR] Process Exit Code: 1
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.awaitResultsDone(ForkStarter.java:494)
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkPerTestSet(ForkStarter.java:441)
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:293)
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
> {noformat}
>  
> The issue is the "free-floating" {{false}} that appears in the command line 
> used to start a new JVM. I've traced down the issue to 
> {{org.apache.maven.plugin.surefire.AbstractSurefireMojo#getEffectiveDebugForkedProcess}}
>  where the following code can be found:
> {code:java}
> String debugForkedProcess = getDebugForkedProcess();
> if ( "true".equals( debugForkedProcess ) )
> {
> return "-Xdebug -Xnoagent -Djava.compiler=NONE"
> + " 
> -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005";
> }
> return debugForkedProcess;
> {code}
> ...which is quite..."unexpected" to see that one can pass in a value of 
> {{true}}, but not a value of {{false}}.
> Please fix with a proper parsing of true/false values for the 
> {{maven.failsafe.debug}} property.



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

[jira] [Updated] (SUREFIRE-1541) SurefireBooterForkException: The forked VM terminated without properly saying goodbye. VM crash or System.exit called?

[Radoslav Ivanov (JIRA)]

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

Radoslav Ivanov updated SUREFIRE-1541:
--
Attachment: hs_err_pid3584.log

> SurefireBooterForkException: The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?
> --
>
> Key: SUREFIRE-1541
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1541
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.22.0
>Reporter: Anghel Botos
>Assignee: Tibor Digana
>Priority: Major
> Attachments: hs_err_pid3584.log
>
>
> Attempting to run integration tests using maven-failsafe-plugin with 
> {{-Dmaven.failsafe.debug=false}} yields the following stacktrace:
>  
> {noformat}
> [ERROR] ExecutionException The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?
> [ERROR] Command was cmd.exe /X /C ""C:\Program 
> Files\Java\jdk1.8.0_121\jre\bin\java" false -jar 
> C:\Users\ANGHEL~1.BOT\AppData\Local\Temp\surefire8539836821793811485\surefirebooter6734575521909210279.jar
>  C:\Users\anghel.botos\AppData\Local\Temp\surefire8539836821793811485 
> 2018-07-24T11-18-12_704-jvmRun1 surefire7184511894589995478tmp 
> surefire_411836142070426630764tmp"
> [ERROR] Error occurred in starting fork, check output in log
> [ERROR] Process Exit Code: 1
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.awaitResultsDone(ForkStarter.java:494)
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkPerTestSet(ForkStarter.java:441)
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:293)
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
> {noformat}
>  
> The issue is the "free-floating" {{false}} that appears in the command line 
> used to start a new JVM. I've traced down the issue to 
> {{org.apache.maven.plugin.surefire.AbstractSurefireMojo#getEffectiveDebugForkedProcess}}
>  where the following code can be found:
> {code:java}
> String debugForkedProcess = getDebugForkedProcess();
> if ( "true".equals( debugForkedProcess ) )
> {
> return "-Xdebug -Xnoagent -Djava.compiler=NONE"
> + " 
> -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005";
> }
> return debugForkedProcess;
> {code}
> ...which is quite..."unexpected" to see that one can pass in a value of 
> {{true}}, but not a value of {{false}}.
> Please fix with a proper parsing of true/false values for the 
> {{maven.failsafe.debug}} property.



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

[GitHub] Tibor17 commented on a change in pull request #199: Surefire 1593

[GitBox]

Tibor17 commented on a change in pull request #199: Surefire 1593
URL: https://github.com/apache/maven-surefire/pull/199#discussion_r233200172
 
 

 ##
 File path: 
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/JarManifestForkConfiguration.java
 ##
 @@ -116,10 +116,10 @@ private File createJar( @Nonnull List classPath, 
@Nonnull String startCl
 StringBuilder cp = new StringBuilder();
 for ( Iterator it = classPath.iterator(); it.hasNext(); )
 {
-File classPathElement = new File( it.next() );
+String classPathElement = it.next();
 String uri = toClasspathElementUri( parent, classPathElement, 
dumpLogDirectory );
 cp.append( uri );
-if ( classPathElement.isDirectory() && !uri.endsWith( "/" ) )
+if ( new File( classPathElement ).isDirectory() && 
!uri.endsWith( "/" ) )
 
 Review comment:
   Thst's correct. The Strings are already platform specific.


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

[GitHub] oflebbe opened a new pull request #6: Update commons-collections

[GitBox]

oflebbe opened a new pull request #6: Update commons-collections
URL: https://github.com/apache/maven-doxia-sitetools/pull/6
 
 
   In order to mute warnings for CVE-2015-6420 and CVE-2017-15708 in 3rd party 
projects. Likely a false positive, just making sure.


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] (MSITE-829) Upgrade Jetty to 9.4.12

[Olaf Flebbe (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSITE-829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16685610#comment-16685610
 ] 

Olaf Flebbe commented on MSITE-829:
---

Not sure what about to do this ticket. Should I refactor the pull request to 
extract the 1.8 dependency code ?

 

 

> Upgrade Jetty to 9.4.12
> ---
>
> Key: MSITE-829
> URL: https://issues.apache.org/jira/browse/MSITE-829
> Project: Maven Site Plugin
>  Issue Type: Task
>Reporter: Olivier Lamy (*$^¨%`£)
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Major
> Fix For: 3.8
>
>




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

[jira] [Issue Comment Deleted] (MSITE-829) Upgrade Jetty to 9.4.12

[Olaf Flebbe (JIRA)]

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

Olaf Flebbe updated MSITE-829:
--
Comment: was deleted

(was: Not sure what about to do this ticket. Should I refactor the pull request 
to extract the 1.8 dependency code ?

 

 )

> Upgrade Jetty to 9.4.12
> ---
>
> Key: MSITE-829
> URL: https://issues.apache.org/jira/browse/MSITE-829
> Project: Maven Site Plugin
>  Issue Type: Task
>Reporter: Olivier Lamy (*$^¨%`£)
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Major
> Fix For: 3.8
>
>




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

[jira] [Commented] (MSITE-828) Jdk 1.8 required

[Olaf Flebbe (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSITE-828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16685612#comment-16685612
 ] 

Olaf Flebbe commented on MSITE-828:
---

Should I squash the git pull request into one commit ?

> Jdk 1.8 required
> 
>
> Key: MSITE-828
> URL: https://issues.apache.org/jira/browse/MSITE-828
> Project: Maven Site Plugin
>  Issue Type: Task
>Reporter: Olivier Lamy (*$^¨%`£)
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Major
> Fix For: 3.8
>
>




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