[jira] [Commented] (SUREFIRE-1422) Forking fails on Linux if /bin/ps isn't available

[Tibor Digana (JIRA)]

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

Tibor Digana commented on SUREFIRE-1422:


Do you have a dump file from target/surefire-reports?
How you found out that the parameter -p is not supported, in logs or in the
dump file?

On Wed, Mar 7, 2018 at 4:06 PM, Andrew Potter (JIRA) 



> Forking fails on Linux if /bin/ps isn't available
> -
>
> Key: SUREFIRE-1422
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1422
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: process forking
>Affects Versions: 2.20.1
> Environment: Linux (Debian 9 with OpenJDK 8)
>Reporter: Emmanuel Bourg
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.21.0
>
>
> Hi,
> With the changes introduced by SUREFIRE-1302 I'm now experiencing a failure 
> on Linux when the fork mode is enabled:
> {code}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test (default-test) on 
> project foo: There are test failures.
> [ERROR]
> [ERROR] Please refer to /foo/target/surefire-reports for the individual test 
> results.
> [ERROR] Please refer to dump files (if any exist) [date]-jvmRun[N].dump, 
> [date].dumpstream and [date]-jvmRun[N].dumpstream.
> [ERROR] The forked VM terminated without properly saying goodbye. VM crash or 
> System.exit called?
> {code}
> I traced the issue back to the PpidChecker class, the code assumes that 
> {{/bin/ps}} or {{/usr/bin/ps}} exist but this isn't guaranteed (especially on 
> trimmed down containers commonly used for continuous integration).
> It would be nice to have a fallback mechanism when ps isn't available, or at 
> least check its existence and display an explicit message stating that it 
> must be installed.



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

[jira] [Commented] (MCOMPILER-205) maven-compiler-plugin: incremental compilation broken

[Robert Scholte (JIRA)]

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

Robert Scholte commented on MCOMPILER-205:
--

I see there's some confusion, so something needs to be changed, maybe improving 
documentation is good enough.
Looking at the code, you'll see that non-incremental will only look at changed 
sourcefiles. Incremental will also verifies if dependencies have changed and if 
files have been added or removed. If it has changed, it'll remove the complete 
classes-directory. The reason is that the default java compiler is quite fast, 
likely much faster than analyzing per file what to do with it.
IIUC the eclipse compiler is a real incremental compiler, so we could decide 
that based that based on the used compiler not to drop the classes directory.

> maven-compiler-plugin: incremental compilation broken
> -
>
> Key: MCOMPILER-205
> URL: https://issues.apache.org/jira/browse/MCOMPILER-205
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Lukas Fryc
>Priority: Major
> Attachments: hello.tgz, ignore-package-info.patch, 
> no-class-in-java-file.zip, only-recompile-changed.patch
>
>
> When we do {{clean}} -> {{compile}} -> {{compile}}, all Java sources are 
> re-compiled for second compilation steps:
> {code}
> [framework]$ mvn clean
> ...
> [framework]$ mvn compile
> ...
> [INFO] --- maven-compiler-plugin:3.1:compile (precompile-sources-for-cdk) @ 
> richfaces-framework ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 915 source files to 
> /mnt/workspace/workspaces/richfaces/richfaces5/framework/target/classes
> ...
> [framework]$ mvn compile
> ...
> [INFO] --- maven-compiler-plugin:3.1:compile (precompile-sources-for-cdk) @ 
> richfaces-framework ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 915 source files to 
> /mnt/workspace/workspaces/richfaces/richfaces5/framework/target/classes
> ...
> {code}
> The source code of the affected project: 
> https://github.com/richfaces/richfaces5/tree/077dcfc0a46d03d7ba9a7ac3e701a4adfb834c71



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

[jira] [Comment Edited] (SUREFIRE-1422) Forking fails on Linux if /bin/ps isn't available

[Thomas Raehalme (JIRA)]

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

Thomas Raehalme edited comment on SUREFIRE-1422 at 3/7/18 6:46 PM:
---

I've written about the issue [on my 
blog|http://raehal.me/maven-surefire-plugin-on-Docker/] with examples of both 
output and contents of the dump file. 

You can verify the ps functionality with Docker:
{code:java}
$ docker run -it --rm maven:3.5.2-jdk-8-alpine /bin/sh
/ # ps --help
BusyBox v1.25.1 (2016-10-26 16:15:20 GMT) multi-call binary.

Usage: ps [-o COL1,COL2=HEADER]

Show list of processes

-o COL1,COL2=HEADER Select columns for display
/ # 
{code}
As you can see the default implementation from BusyBox in Alpine is rather 
limited regarding options.

But if you install the {{procps}} package, you get the needed options.
{code:java}
$ docker run -it --rm maven:3.5.2-jdk-8-alpine /bin/sh
/ # apk add --update procps
fetch http://dl-cdn.alpinelinux.org/alpine/v3.5/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.5/community/x86_64/APKINDEX.tar.gz
(1/3) Installing libintl (0.19.8.1-r0)
(2/3) Installing libproc (3.3.12-r1)
(3/3) Installing procps (3.3.12-r1)
Executing busybox-1.25.1-r0.trigger
OK: 110 MiB in 62 packages
/ # ps --help all

Usage:
 ps [options]

Basic options:
 -A, -e   all processes
 -a   all with tty, except session leaders
  a   all with tty, including other users
 -d   all except session leaders
 -N, --deselect   negate selection
  r   only running processes
  T   all processes on this terminal
  x   processes without controlling ttys

Selection by list:
 -C  command name
 -G, --Group real group id or name
 -g, --group   session or effective group name
 -p, p, --pidprocess id
--ppid   parent process id
 -q, q, --quick-pid 
  process id (quick mode)
 -s, --sid   session id
 -t, t, --ttyterminal
 -u, U, --user   effective user id or name
 -U, --User  real user id or name

  The selection options take as their argument either:
a comma-separated list e.g. '-u root,nobody' or
a blank-separated list e.g. '-p 123 4567'

Output formats:
 -F   extra full
 -f   full-format, including command lines
  f, --forest ascii art process tree
 -H   show process hierarchy
 -j   jobs format
  j   BSD job control format
 -l   long format
  l   BSD long format
 -M, Zadd security data (for SELinux)
 -O   preloaded with default columns
  O   as -O, with BSD personality
 -o, o, --format 
  user-defined format
  s   signal format
  u   user-oriented format
  v   virtual memory format
  X   register format
 -y   do not show flags, show rss vs. addr (used with -l)
 --contextdisplay security context (for SELinux)
 --headersrepeat header lines, one per page
 --no-headers do not print header at all
 --cols, --columns, --width 
  set screen width
 --rows, --lines 
  set screen height

Show threads:
  H   as if they were processes
 -L   possibly with LWP and NLWP columns
 -m, mafter processes
 -T   possibly with SPID column

Miscellaneous options:
 -c   show scheduling class with -l option
  c   show true command name
  e   show the environment after command
  k,--sortspecify sort order as: [+|-]key[,[+|-]key[,...]]
  L   show format specifiers
  n   display numeric uid and wchan
  S,--cumulative  include some dead child process data
 -y   do not show flags, show rss (only with -l)
 -V, V, --version display version information and exit
 -w, wunlimited output width

--help 
  display help and exit

For more details see ps(1).
/ # 
{code}
The problem only occurs when the {{procps}} package has not been installed.

Hope this helps! If I can help with anything please let me know.


was (Author: raehalme):
I've written about the issue [on my 
blog|http://raehal.me/maven-surefire-plugin-on-Docker/] with examples of both 
output and contents of the dump file. 

You can verify the ps functionality with Docker:
{code}
$ docker run -it --rm maven:3.5.2-jdk-8-alpine /bin/sh
/ # ps --help
BusyBox v1.25.1 (2016-10-26 16:15:20 GMT) multi-call binary.

Usage: ps [-o COL1,COL2=HEADER]

Show list of processes

-o COL1,COL2=HEADER Select columns for display
/ 

[jira] [Commented] (SUREFIRE-1422) Forking fails on Linux if /bin/ps isn't available

[Thomas Raehalme (JIRA)]

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

Thomas Raehalme commented on SUREFIRE-1422:
---

I've written about the issue [on my 
blog|http://raehal.me/maven-surefire-plugin-on-Docker/] with examples of both 
output and contents of the dump file. 

You can verify the ps functionality with Docker:
{code}
$ docker run -it --rm maven:3.5.2-jdk-8-alpine /bin/sh
/ # ps --help
BusyBox v1.25.1 (2016-10-26 16:15:20 GMT) multi-call binary.

Usage: ps [-o COL1,COL2=HEADER]

Show list of processes

-o COL1,COL2=HEADER Select columns for display
/ # 
{code}
As you can see the default implementation from BusyBox in Alpine is rather 
limited regarding options.

But if you install the {{procps}} package, you get the needed options.
{code}
$ docker run -it --rm maven:3.5.2-jdk-8-alpine /bin/sh
/ # apk add --update procps
fetch http://dl-cdn.alpinelinux.org/alpine/v3.5/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.5/community/x86_64/APKINDEX.tar.gz
(1/3) Installing libintl (0.19.8.1-r0)
(2/3) Installing libproc (3.3.12-r1)
(3/3) Installing procps (3.3.12-r1)
Executing busybox-1.25.1-r0.trigger
OK: 110 MiB in 62 packages
/ # ps --help all

Usage:
 ps [options]

Basic options:
 -A, -e   all processes
 -a   all with tty, except session leaders
  a   all with tty, including other users
 -d   all except session leaders
 -N, --deselect   negate selection
  r   only running processes
  T   all processes on this terminal
  x   processes without controlling ttys

Selection by list:
 -C  command name
 -G, --Group real group id or name
 -g, --group   session or effective group name
 -p, p, --pidprocess id
--ppid   parent process id
 -q, q, --quick-pid 
  process id (quick mode)
 -s, --sid   session id
 -t, t, --ttyterminal
 -u, U, --user   effective user id or name
 -U, --User  real user id or name

  The selection options take as their argument either:
a comma-separated list e.g. '-u root,nobody' or
a blank-separated list e.g. '-p 123 4567'

Output formats:
 -F   extra full
 -f   full-format, including command lines
  f, --forest ascii art process tree
 -H   show process hierarchy
 -j   jobs format
  j   BSD job control format
 -l   long format
  l   BSD long format
 -M, Zadd security data (for SELinux)
 -O   preloaded with default columns
  O   as -O, with BSD personality
 -o, o, --format 
  user-defined format
  s   signal format
  u   user-oriented format
  v   virtual memory format
  X   register format
 -y   do not show flags, show rss vs. addr (used with -l)
 --contextdisplay security context (for SELinux)
 --headersrepeat header lines, one per page
 --no-headers do not print header at all
 --cols, --columns, --width 
  set screen width
 --rows, --lines 
  set screen height

Show threads:
  H   as if they were processes
 -L   possibly with LWP and NLWP columns
 -m, mafter processes
 -T   possibly with SPID column

Miscellaneous options:
 -c   show scheduling class with -l option
  c   show true command name
  e   show the environment after command
  k,--sortspecify sort order as: [+|-]key[,[+|-]key[,...]]
  L   show format specifiers
  n   display numeric uid and wchan
  S,--cumulative  include some dead child process data
 -y   do not show flags, show rss (only with -l)
 -V, V, --version display version information and exit
 -w, wunlimited output width

--help 
  display help and exit

For more details see ps(1).
/ # 
{code}
Hope this helps! If I can help with anything please let me know.

> Forking fails on Linux if /bin/ps isn't available
> -
>
> Key: SUREFIRE-1422
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1422
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: process forking
>Affects Versions: 2.20.1
> Environment: Linux (Debian 9 with OpenJDK 8)
>Reporter: Emmanuel Bourg
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.21.0
>
>
> Hi,
> With the changes introduced by SUREFIRE-1302 I'm now 

[jira] [Commented] (MEAR-258) Upgrade site skin to 1.7

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MEAR-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16390177#comment-16390177
 ] 

Hudson commented on MEAR-258:
-

Build succeeded in Jenkins: Maven TLP » maven-ear-plugin » CLEANUP #3

See https://builds.apache.org/job/maven-box/job/maven-ear-plugin/job/CLEANUP/3/

> Upgrade site skin to 1.7
> 
>
> Key: MEAR-258
> URL: https://issues.apache.org/jira/browse/MEAR-258
> Project: Maven Ear Plugin
>  Issue Type: Improvement
>Affects Versions: 3.0.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: 3.0.0
>
>
> Currently the skin is on version 1.4 which will not work with Maven Site 
> Plugin 3.7...



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

[jira] [Closed] (MEAR-258) Upgrade site skin to 1.7

[Karl Heinz Marbaise (JIRA)]

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

Karl Heinz Marbaise closed MEAR-258.

Resolution: Fixed

Done in 
[030cf8d6fc67e65d83467af24721181223d50bac|https://gitbox.apache.org/repos/asf?p=maven-ear-plugin.git;a=commitdiff;h=030cf8d6fc67e65d83467af24721181223d50bac]

> Upgrade site skin to 1.7
> 
>
> Key: MEAR-258
> URL: https://issues.apache.org/jira/browse/MEAR-258
> Project: Maven Ear Plugin
>  Issue Type: Improvement
>Affects Versions: 3.0.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: 3.0.0
>
>
> Currently the skin is on version 1.4 which will not work with Maven Site 
> Plugin 3.7...



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

[jira] [Created] (MDEPLOY-232) Using maven-fluido-skin 1.7

[Karl Heinz Marbaise (JIRA)]

Karl Heinz Marbaise created MDEPLOY-232:
---

 Summary: Using maven-fluido-skin 1.7
 Key: MDEPLOY-232
 URL: https://issues.apache.org/jira/browse/MDEPLOY-232
 Project: Maven Deploy Plugin
  Issue Type: Improvement
Affects Versions: 3.0.0
Reporter: Karl Heinz Marbaise
Assignee: Karl Heinz Marbaise
 Fix For: 3.0.0






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

[jira] [Updated] (MEAR-213) WARNING Output is not correct in case of classifiers

[Karl Heinz Marbaise (JIRA)]

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

Karl Heinz Marbaise updated MEAR-213:
-
Fix Version/s: (was: 3.0.0)
   3.0.1

> WARNING Output is not correct in case of classifiers
> 
>
> Key: MEAR-213
> URL: https://issues.apache.org/jira/browse/MEAR-213
> Project: Maven Ear Plugin
>  Issue Type: Improvement
>Affects Versions: 2.10
>Reporter: Karl Heinz Marbaise
>Priority: Major
> Fix For: 3.0.1
>
>
> In relationship with classifier this does not work correctly.
> {noformat}
> [INFO] --- maven-ear-plugin:2.10:ear (default-ear) @ middletier-ear ---
> [WARNING] The artifactId component-base:6.33.10-SNAPSHOT exists more than 
> once in the modules list.
> [WARNING]  --> com.company:component-base:jar:6.33.10-SNAPSHOT (jar)
> [WARNING]  --> com.company:component-base:jar:qclasses:6.33.10-SNAPSHOT (jar)
> [WARNING] The artifactId component-func:6.33.10-SNAPSHOT exists more than 
> once in the modules list.
> [WARNING]  --> com.company:component-func:jar:6.33.10-SNAPSHOT (jar)
> [WARNING]  --> com.company:component-func:jar:qclasses:6.33.10-SNAPSHOT (jar)
> [WARNING] HINT: This can be simply solved by using the 
> full
> {noformat}



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

[jira] [Updated] (MEAR-216) Unable to include dependencies of type test-jar

[Karl Heinz Marbaise (JIRA)]

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

Karl Heinz Marbaise updated MEAR-216:
-
Fix Version/s: (was: 3.0.0)
   3.0.1

> Unable to include dependencies of type test-jar
> ---
>
> Key: MEAR-216
> URL: https://issues.apache.org/jira/browse/MEAR-216
> Project: Maven Ear Plugin
>  Issue Type: Improvement
>Affects Versions: 2.10
>Reporter: Maxim Frolov
>Priority: Blocker
> Fix For: 3.0.1
>
> Attachments: test-jar-in-ear-2.zip, test-jar-in-ear.zip
>
>
> Please implement support for artifacts of type *test-jar*.
> One of the use cases would be to build a test EAR as a mix of production and 
> test JARs where the test JARs are used to set up the test data used to test 
> the production code.
> Currently including one or more dependencies of type test-jar causes 
> *LifecycleExecutionException*: 
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-ear-plugin:2.10:generate-application-xml 
> (default-generate-application-xml) on project suite-systemtests-common-ear: 
> Failed to initialize ear modules: Unknown artifact type[test-jar] for 
> artifact_id -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-ear-plugin:2.10:generate-application-xml 
> (default-generate-application-xml) on project suite-systemtests-common-ear: 
> Failed to initialize ear modules
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
> 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:84)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to 
> initialize ear modules
> at 
> org.apache.maven.plugin.ear.AbstractEarMojo.execute(AbstractEarMojo.java:260)
> at 
> org.apache.maven.plugin.ear.GenerateApplicationXmlMojo.execute(GenerateApplicationXmlMojo.java:162)
> at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 19 more
> Caused by: org.apache.maven.plugin.ear.UnknownArtifactTypeException: Unknown 
> artifact type[test-jar] for common-domain-impl
> at 
> org.apache.maven.plugin.ear.EarModuleFactory.newEarModule(EarModuleFactory.java:88)
> at 
> org.apache.maven.plugin.ear.AbstractEarMojo.execute(AbstractEarMojo.java:250)
> ... 22 more
> {noformat}



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

[jira] [Closed] (MSHARED-696) Add missing Maven Version 3.5.2 to ArtifactDeployerTest

[Karl Heinz Marbaise (JIRA)]

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

Karl Heinz Marbaise closed MSHARED-696.
---
Resolution: Fixed

Done in 
[4d6b16ab20e9a32b5b2ff2d9049a6dcecffbc79e|https://gitbox.apache.org/repos/asf?p=maven-artifact-transfer.git;a=commitdiff;h=4d6b16ab20e9a32b5b2ff2d9049a6dcecffbc79e]

> Add missing Maven Version 3.5.2 to ArtifactDeployerTest
> ---
>
> Key: MSHARED-696
> URL: https://issues.apache.org/jira/browse/MSHARED-696
> Project: Maven Shared Components
>  Issue Type: Improvement
>  Components: maven-artifact-transfer
>Affects Versions: maven-artifact-transfer-0.10.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: maven-artifact-transfer-0.10.0
>
>




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

[jira] [Created] (MEAR-258) Upgrade site skin to 1.7

[Karl Heinz Marbaise (JIRA)]

Karl Heinz Marbaise created MEAR-258:


 Summary: Upgrade site skin to 1.7
 Key: MEAR-258
 URL: https://issues.apache.org/jira/browse/MEAR-258
 Project: Maven Ear Plugin
  Issue Type: Improvement
Affects Versions: 3.0.0
Reporter: Karl Heinz Marbaise
Assignee: Karl Heinz Marbaise
 Fix For: 3.0.0


Currently the skin is on version 1.4 which will not work with Maven Site Plugin 
3.7...



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

[jira] [Comment Edited] (SUREFIRE-1422) Forking fails on Linux if /bin/ps isn't available

[Thomas Raehalme (JIRA)]

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

Thomas Raehalme edited comment on SUREFIRE-1422 at 3/7/18 6:48 PM:
---

I've written about the issue [on my 
blog|http://raehal.me/maven-surefire-plugin-on-Docker/] with examples of both 
output and contents of the dump file. 

You can verify the ps functionality with Docker:
{code:java}
$ docker run -it --rm maven:3.5.2-jdk-8-alpine /bin/sh
/ # ps --help
BusyBox v1.25.1 (2016-10-26 16:15:20 GMT) multi-call binary.

Usage: ps [-o COL1,COL2=HEADER]

Show list of processes

-o COL1,COL2=HEADER Select columns for display
/ # 
{code}
As you can see the default implementation from BusyBox in Alpine is rather 
limited regarding options. And this is when the problem occurs with the 2.21.0 
version. If you downgrade to version 2.20 there is no problem.

Also if you install the {{procps}} package, you get the needed options and then 
also 2.21.0 works as intended.
{code:java}
$ docker run -it --rm maven:3.5.2-jdk-8-alpine /bin/sh
/ # apk add --update procps
fetch http://dl-cdn.alpinelinux.org/alpine/v3.5/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.5/community/x86_64/APKINDEX.tar.gz
(1/3) Installing libintl (0.19.8.1-r0)
(2/3) Installing libproc (3.3.12-r1)
(3/3) Installing procps (3.3.12-r1)
Executing busybox-1.25.1-r0.trigger
OK: 110 MiB in 62 packages
/ # ps --help all

Usage:
 ps [options]

Basic options:
 -A, -e   all processes
 -a   all with tty, except session leaders
  a   all with tty, including other users
 -d   all except session leaders
 -N, --deselect   negate selection
  r   only running processes
  T   all processes on this terminal
  x   processes without controlling ttys

Selection by list:
 -C  command name
 -G, --Group real group id or name
 -g, --group   session or effective group name
 -p, p, --pidprocess id
--ppid   parent process id
 -q, q, --quick-pid 
  process id (quick mode)
 -s, --sid   session id
 -t, t, --ttyterminal
 -u, U, --user   effective user id or name
 -U, --User  real user id or name

  The selection options take as their argument either:
a comma-separated list e.g. '-u root,nobody' or
a blank-separated list e.g. '-p 123 4567'

Output formats:
 -F   extra full
 -f   full-format, including command lines
  f, --forest ascii art process tree
 -H   show process hierarchy
 -j   jobs format
  j   BSD job control format
 -l   long format
  l   BSD long format
 -M, Zadd security data (for SELinux)
 -O   preloaded with default columns
  O   as -O, with BSD personality
 -o, o, --format 
  user-defined format
  s   signal format
  u   user-oriented format
  v   virtual memory format
  X   register format
 -y   do not show flags, show rss vs. addr (used with -l)
 --contextdisplay security context (for SELinux)
 --headersrepeat header lines, one per page
 --no-headers do not print header at all
 --cols, --columns, --width 
  set screen width
 --rows, --lines 
  set screen height

Show threads:
  H   as if they were processes
 -L   possibly with LWP and NLWP columns
 -m, mafter processes
 -T   possibly with SPID column

Miscellaneous options:
 -c   show scheduling class with -l option
  c   show true command name
  e   show the environment after command
  k,--sortspecify sort order as: [+|-]key[,[+|-]key[,...]]
  L   show format specifiers
  n   display numeric uid and wchan
  S,--cumulative  include some dead child process data
 -y   do not show flags, show rss (only with -l)
 -V, V, --version display version information and exit
 -w, wunlimited output width

--help 
  display help and exit

For more details see ps(1).
/ # 
{code}
Hope this helps! If I can help with anything please let me know.


was (Author: raehalme):
I've written about the issue [on my 
blog|http://raehal.me/maven-surefire-plugin-on-Docker/] with examples of both 
output and contents of the dump file. 

You can verify the ps functionality with Docker:
{code:java}
$ docker run -it --rm maven:3.5.2-jdk-8-alpine /bin/sh
/ # ps --help
BusyBox v1.25.1 (2016-10-26 16:15:20 GMT) multi-call binary.

Usage: ps [-o 

[jira] [Commented] (SUREFIRE-1497) Flag to select modulepath or classpath

[Robert Scholte (JIRA)]

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

Robert Scholte commented on SUREFIRE-1497:
--

Looks to me like this is just in theory. If you have a module descriptor and 
you are not able to run unittests with modulepath,  then you are likely to have 
issues at runtime as well. IMHO we should only consider this if there's a 
testcase attached hitting this issue and we all agree on that such a flag is 
the only valid solution. 


> Flag to select modulepath or classpath
> --
>
> Key: SUREFIRE-1497
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1497
> Project: Maven Surefire
>  Issue Type: Improvement
>Affects Versions: 2.21.0
>Reporter: Stephen Colebourne
>Priority: Major
>
> SUREFIRE-1262 added the ability to run tests using the modulepath, which is 
> great. However, as a library developer I cannot guarantee that the code will 
> be run on the modulepath, it might well be run on the classpath.
> As such, can I request a flag that turns the behaviour in SUREFIRE-1262 on 
> and off? This would allow a single pom.xml to run surefire twice, once with 
> the code on the modulepath and once with the code on the classpath, to ensure 
> that the behaviour always works however the code is run. (Other solutions to 
> achieve the same goal may be possible, but this seems the most obvious).



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

[jira] [Commented] (MCOMPILER-320) Allow additional class path items to be given during compilation

[Robert Scholte (JIRA)]

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

Robert Scholte commented on MCOMPILER-320:
--

To be honest: no, other Maven projects have my attention now. I've noticed that 
the maven-compiler-plugin is unstable on our build-server (not related to this 
change) which would be one of the first things to pick up when working on this 
plugin again.

> Allow additional class path items to be given during compilation
> 
>
> Key: MCOMPILER-320
> URL: https://issues.apache.org/jira/browse/MCOMPILER-320
> Project: Maven Compiler Plugin
>  Issue Type: New Feature
>Reporter: David M. Lloyd
>Priority: Major
> Fix For: 3.7.1
>
>
> At present it is very difficult to include additional class path items during 
> compilation that are not dependencies.  But this is a very useful capability, 
> especially when doing partial builds, MR JARs, JDK API stubbing, including 
> dependency items that cannot be included in any other build phase or 
> execution, etc.
> This enhancement and pull request are to request the addition of a 
> {{additionalCompilePathItems}} property in CompilerMojo or 
> AbstractCompilerMojo which includes additional filesystem paths in the 
> compilation class path.



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

[jira] [Commented] (MEAR-258) Upgrade site skin to 1.7

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MEAR-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16390136#comment-16390136
 ] 

Hudson commented on MEAR-258:
-

Build succeeded in Jenkins: Maven TLP » maven-ear-plugin » master #9

See https://builds.apache.org/job/maven-box/job/maven-ear-plugin/job/master/9/

> Upgrade site skin to 1.7
> 
>
> Key: MEAR-258
> URL: https://issues.apache.org/jira/browse/MEAR-258
> Project: Maven Ear Plugin
>  Issue Type: Improvement
>Affects Versions: 3.0.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: 3.0.0
>
>
> Currently the skin is on version 1.4 which will not work with Maven Site 
> Plugin 3.7...



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

[jira] [Commented] (MDEPLOY-232) Using maven-fluido-skin 1.7

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MDEPLOY-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16390235#comment-16390235
 ] 

Hudson commented on MDEPLOY-232:


Build succeeded in Jenkins: Maven TLP » maven-deploy-plugin » master #4

See 
https://builds.apache.org/job/maven-box/job/maven-deploy-plugin/job/master/4/

> Using maven-fluido-skin 1.7
> ---
>
> Key: MDEPLOY-232
> URL: https://issues.apache.org/jira/browse/MDEPLOY-232
> Project: Maven Deploy Plugin
>  Issue Type: Improvement
>Affects Versions: 3.0.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.0
>
>




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

[jira] [Created] (MDEPLOY-233) Remove unused code

[Karl Heinz Marbaise (JIRA)]

Karl Heinz Marbaise created MDEPLOY-233:
---

 Summary: Remove unused code
 Key: MDEPLOY-233
 URL: https://issues.apache.org/jira/browse/MDEPLOY-233
 Project: Maven Deploy Plugin
  Issue Type: Improvement
Affects Versions: 3.0.0
Reporter: Karl Heinz Marbaise
Assignee: Karl Heinz Marbaise
 Fix For: 3.0.0






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

[jira] [Commented] (MNG-6370) ConcurrencyDependencyGraph#getNumberOfBuilds() does not remove finished projects from unfinished ones

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MNG-6370:
-

Github user slachiewicz commented on the issue:

https://github.com/apache/maven/pull/161
  
Sure, unit test are always funny part:) done


> ConcurrencyDependencyGraph#getNumberOfBuilds() does not remove finished 
> projects from unfinished ones
> -
>
> Key: MNG-6370
> URL: https://issues.apache.org/jira/browse/MNG-6370
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.5.2, 3.5.3
>Reporter: Sylwester Lachiewicz
>Assignee: Michael Osipov
>Priority: Trivial
> Fix For: 3.5.4-candidate
>
>
> Fix _ConcurrencyDependencyGraph.getUnfinishedProjects_
> {code:java}
> private final HashSet finishedProjects = new HashSet<>();
> /**
>  * @return set of projects that have yet to be processed successfully by the 
> build.
>  */
> public Set getUnfinishedProjects()
> {
>  Set unfinished = new HashSet<>( projectBuilds.getProjects() );
>  unfinished.remove( finishedProjects );
>  return unfinished;
> }{code}
> replace _remove()_ with _removeAll()_



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

[jira] [Updated] (MNG-6372) On Windows with -T option, Maven can output spurious ANSI escapes such as [0m [0m

[Stephen Connolly (JIRA)]

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

Stephen Connolly updated MNG-6372:
--
Summary: On Windows with -T option, Maven can output spurious ANSI escapes 
such as [0m [0m  (was: On Windows with -T option, Maven can output spurios ANSI 
escapes such as {{[0m [0m}})

> On Windows with -T option, Maven can output spurious ANSI escapes such as [0m 
> [0m
> -
>
> Key: MNG-6372
> URL: https://issues.apache.org/jira/browse/MNG-6372
> Project: Maven
>  Issue Type: New Feature
>Affects Versions: 3.5.3
>Reporter: Stephen Connolly
>Priority: Major
>
> Found during the release vote of Maven 3.5.3
> A regression introduced by the upgrade of JAnsi to 1.17. Rumoured fixed in 
> 1.18



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

[jira] [Updated] (MNG-5828) Artifact download loses proxy username during transfer, failing download

[Michael Osipov (JIRA)]

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

Michael Osipov updated MNG-5828:

Labels: close-pending  (was: )

> Artifact download loses proxy username during transfer, failing download
> 
>
> Key: MNG-5828
> URL: https://issues.apache.org/jira/browse/MNG-5828
> Project: Maven
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 3.3.3
> Environment: Windows 7 Enterprise SP1 x64
>Reporter: John Elion
>Priority: Minor
>  Labels: close-pending
> Attachments: failed-dbg.log, failed.log, pom.xml, settings.xml
>
>
> Executing 'mvn site' causes Maven to successfully download most artifacts, 
> but several failures are reported with the message 
> [WARNING] Could not transfer metadata 
> org.codehaus.mojo:findbugs-maven-plugin/maven-metadata.xml from/to central 
> (https://repo.maven.apache.org/maven2): Error transferring file: Unable to 
> tunnel through proxy. Proxy returns "HTTP/1.1 407 authenticationrequired" 
> from 
> https://repo.maven.apache.org/maven2/org/codehaus/mojo/findbugs-maven-plugin/maven-metadata.xml
>  with proxyInfo ProxyInfo{host='mamwg.gdc4s.com', userName='null', port=8080, 
> type='https', nonProxyHosts='null'}
> The proxy configuration does specify a username, and a "mvn -X" log shows 
> Maven to be aware of the username a few lines earlier.
> [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for 
> https://repo.maven.apache.org/maven2 via mamwg.gdc4s.com:8080 with 
> username=p58042, password=***
> I don't see a way to attach, but if I can do so after saving I will attach a 
> fairly simple pom file, settings.xml (stripped of passwords), and plain and 
> debug log files that will reproduce the error with the commands 'mvn -s 
> settings.xml site' and 'mvn -X -s settings.xml site'.
> I have listed this as "minor" because my end build results thus far have been 
> successful and the components which have failed to download have apparently 
> not impacted my building or testing - in some cases it appears the component 
> is already downloaded to my local repository; however, there are hundreds of 
> these warnings in my build logs.



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

[jira] [Commented] (MNG-5828) Artifact download loses proxy username during transfer, failing download

[Michael Osipov (JIRA)]

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

Michael Osipov commented on MNG-5828:
-

Is this one still valid?

> Artifact download loses proxy username during transfer, failing download
> 
>
> Key: MNG-5828
> URL: https://issues.apache.org/jira/browse/MNG-5828
> Project: Maven
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 3.3.3
> Environment: Windows 7 Enterprise SP1 x64
>Reporter: John Elion
>Priority: Minor
>  Labels: close-pending
> Attachments: failed-dbg.log, failed.log, pom.xml, settings.xml
>
>
> Executing 'mvn site' causes Maven to successfully download most artifacts, 
> but several failures are reported with the message 
> [WARNING] Could not transfer metadata 
> org.codehaus.mojo:findbugs-maven-plugin/maven-metadata.xml from/to central 
> (https://repo.maven.apache.org/maven2): Error transferring file: Unable to 
> tunnel through proxy. Proxy returns "HTTP/1.1 407 authenticationrequired" 
> from 
> https://repo.maven.apache.org/maven2/org/codehaus/mojo/findbugs-maven-plugin/maven-metadata.xml
>  with proxyInfo ProxyInfo{host='mamwg.gdc4s.com', userName='null', port=8080, 
> type='https', nonProxyHosts='null'}
> The proxy configuration does specify a username, and a "mvn -X" log shows 
> Maven to be aware of the username a few lines earlier.
> [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for 
> https://repo.maven.apache.org/maven2 via mamwg.gdc4s.com:8080 with 
> username=p58042, password=***
> I don't see a way to attach, but if I can do so after saving I will attach a 
> fairly simple pom file, settings.xml (stripped of passwords), and plain and 
> debug log files that will reproduce the error with the commands 'mvn -s 
> settings.xml site' and 'mvn -X -s settings.xml site'.
> I have listed this as "minor" because my end build results thus far have been 
> successful and the components which have failed to download have apparently 
> not impacted my building or testing - in some cases it appears the component 
> is already downloaded to my local repository; however, there are hundreds of 
> these warnings in my build logs.



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

[jira] [Closed] (MNGSITE-238) Many dead links on webpage Maven Resource Plugin page!

[Michael Osipov (JIRA)]

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

Michael Osipov closed MNGSITE-238.
--
Resolution: Cannot Reproduce

> Many dead links on webpage Maven Resource Plugin page!
> --
>
> Key: MNGSITE-238
> URL: https://issues.apache.org/jira/browse/MNGSITE-238
> Project: Maven Project Web Site
>  Issue Type: Bug
>Reporter: Colbert Philippe
>Priority: Major
>
> Many links on the left menu are dead.   Look at links 
> http://maven.apache.org/plugins/maven-resources-plugin/
> - Filtering 
> - Including and excluding files and directories 
> - Escape Filtering 
> - Copy Resources 
> - Binaries Filtering 
> - Custom Resources Filters



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

[jira] [Commented] (SUREFIRE-1497) Flag to select modulepath or classpath

[Stephen Colebourne (JIRA)]

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

Stephen Colebourne commented on SUREFIRE-1497:
--

 The goal of the issue is to match how the library will be used. It might be 
used on the modulepath or it might be used on the classpath. There is no way 
that I as library author can control which approach the end-user will use. As 
such, I need a way to test the library in both ways.

Today, I changed the surefire version from v2.20.1 to v2.21.0. This found two 
separate cases where the module I had setup was incorrect. Now that it is setup 
correctly, surefire v2.21.0 tests this. However, in order to know whether the 
code still works on the classpath, the only option surefire has at present is 
to temporarily downgrade the version and re-run the tests.

This is not theoretical either. To use ServiceLoader in Java 9 you have to 
duplicate the configuration. Once in META-INF/services and once in 
module-info.java. As it stands, there is no way in v2.21.0 to test the 
META-INF/services config, as that config is only used when the module is on the 
classpath.

A test case exposing this would be a module where META-INF/services is missing 
or wrong, but the module-info.java provides clause is correct.

> Flag to select modulepath or classpath
> --
>
> Key: SUREFIRE-1497
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1497
> Project: Maven Surefire
>  Issue Type: Improvement
>Affects Versions: 2.21.0
>Reporter: Stephen Colebourne
>Priority: Major
>
> SUREFIRE-1262 added the ability to run tests using the modulepath, which is 
> great. However, as a library developer I cannot guarantee that the code will 
> be run on the modulepath, it might well be run on the classpath.
> As such, can I request a flag that turns the behaviour in SUREFIRE-1262 on 
> and off? This would allow a single pom.xml to run surefire twice, once with 
> the code on the modulepath and once with the code on the classpath, to ensure 
> that the behaviour always works however the code is run. (Other solutions to 
> achieve the same goal may be possible, but this seems the most obvious).



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

[jira] [Closed] (MNG-5437) Do not load plugins from snapshot JARs

[Michael Osipov (JIRA)]

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

Michael Osipov closed MNG-5437.
---
Resolution: Won't Fix

I have experienced the very same issue with Java 8 and recent Maven 3.5.x on 
FreeBSD in  Maven Integration Testing Suite. One would actually need to rework 
ITs for this.

Give that one can disable {{mmap}} via system property and Java 9 does not use 
native code anymore for this. Closing as won't fix.

> Do not load plugins from snapshot JARs
> --
>
> Key: MNG-5437
> URL: https://issues.apache.org/jira/browse/MNG-5437
> Project: Maven
>  Issue Type: Bug
>  Components: Class Loading
>Affects Versions: 3.0.4
> Environment: Solaris 10, JDK 1.7.0
>Reporter: Jesse Glick
>Priority: Minor
>
> See [mailing list 
> discussion|http://mail-archives.apache.org/mod_mbox/www-builds/201302.mbox/browser]
>  for background. When a reactor build creates a plugin JAR and then loads 
> classes from it, a JVM crash is a possibility:
> {code:none}
> [INFO] Installing 
> /export/home/hudson/hudson-slave/workspace/sis-jdk7/sis-build-helper/target/sis-build-helper-0.3-jdk7-SNAPSHOT.jar
>  to 
> /export/home/hudson/hudson-slave/maven-repositories/0/org/apache/sis/sis-build-helper/0.3-jdk7-SNAPSHOT/sis-build-helper-0.3-jdk7-SNAPSHOT.jar
> ...moving on to another project in the reactor...
> [INFO] --- sis-build-helper:0.3-jdk7-SNAPSHOT:collect-jars (default) @ 
> sis-utility ---
> #
> # A fatal error has been detected by the Java Runtime Environment:
> {code}
> This could happen for example if two people were running the same build 
> concurrently; if one Maven process is trying to load classes from the JAR at 
> the same time as another is rebuilding that JAR, there will be a problem. On 
> Windows, one of the processes will simply fail with an I/O error due to 
> mandatory file locks. On Unix, the OS will not stop the clash in this way, 
> but there will be a worse issue: {{libzip.so}} will be trying to load a ZIP 
> entry based on a stale copy of the ZIP index, so it loads bogus data, and 
> (being not very robustly written) crashes, taking the whole JVM with it.
> Since this class of problem is most likely to occur when loading classes from 
> {{SNAPSHOT}} JARs in the local repository, I would suggest Maven simply not 
> do this. Instead, use {{File.createTempFile}} to make a new {{/tmp/*.jar}}; 
> use {{deleteOnExit}} to clean it up at process end (or if possible delete it 
> sooner, e.g. upon conclusion of the reactor build, or at any time when it can 
> be determined that mojo execution from this JAR must have ceased); copy the 
> snapshot JAR from the local repo to this temp location; and load from there.
> This means that problems will be limited to the much less likely event that 
> someone is rebuilding the JAR during the very short period during which the 
> file copy happens. And on Unix, the result might be a corrupted JAR file (and 
> thus class loading errors which fail the build somehow), but not a mysterious 
> JVM crash.
> If this proposal sounds good, let me know and I can try to write a patch. 
> (GitHub pull request would be easiest; I am an Apache committer.)



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

[jira] [Commented] (MASSEMBLY-875) Maven 3.x is about 10x slower than 2.6

[Jason Cote (JIRA)]

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

Jason Cote commented on MASSEMBLY-875:
--

I am noticing the same poor assembly performance in one of my projects after 
adding a certain dependency (Bouncycastle in this case):
{code:xml}

org.bouncycastle
bcprov-jdk15on
1.59

{code}

Now when doing a {{mvn package}} to build a fat jar using maven-assembly-plugin 
3.1.0, the process takes 2+ minutes.

If downgrade to version 2.6 it only take ~12 seconds.  Alternatively changing 
to use the maven-shade-plugin instead can also produce the jar for me in ~10 
seconds.

I can work on putting together a public repo to reproduce if needed.

> Maven 3.x is about 10x slower than 2.6
> --
>
> Key: MASSEMBLY-875
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-875
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>Reporter: Stu
>Priority: Minor
>
> In all our java projects, we have a fairly basic assembly configuration, 
> something like this:
> {code:java}
> 
> maven-assembly-plugin
> 2.6
> 
> 
> 
> org.x.x.x
> 
> 
> 
> jar-with-dependencies
> 
> 
> 
> 
> make-assembly
> package
> 
> single
> 
> 
> 
> {code}
> They all take about 10x longer with any 3.x.x version of the maven assembly 
> plugin than the 2.6 version.
> This has been noticed by others:
> [https://stackoverflow.com/questions/9009232/what-sort-of-configuration-issues-or-problems-might-make-maven-assembly-plugin-g/24519615#24519615]
> But not reported as a bug that I could find.
> Although I could only justify "Minor" for the priority, this is really is a 
> blocker for us moving to 3.x.x
> The upgrade is just not worth taking your build from < 10 sec to > 50 sec.
> (For this particular build, it went from about ~ 7 sec to ~ 57 sec.)



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

[jira] [Commented] (MNG-6370) ConcurrencyDependencyGraph#getNumberOfBuilds() does not remove finished projects from unfinished ones

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MNG-6370:
-

Github user asfgit closed the pull request at:

https://github.com/apache/maven/pull/161


> ConcurrencyDependencyGraph#getNumberOfBuilds() does not remove finished 
> projects from unfinished ones
> -
>
> Key: MNG-6370
> URL: https://issues.apache.org/jira/browse/MNG-6370
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.5.2, 3.5.3
>Reporter: Sylwester Lachiewicz
>Assignee: Michael Osipov
>Priority: Trivial
> Fix For: 3.5.4
>
>
> Fix _ConcurrencyDependencyGraph.getUnfinishedProjects_
> {code:java}
> private final HashSet finishedProjects = new HashSet<>();
> /**
>  * @return set of projects that have yet to be processed successfully by the 
> build.
>  */
> public Set getUnfinishedProjects()
> {
>  Set unfinished = new HashSet<>( projectBuilds.getProjects() );
>  unfinished.remove( finishedProjects );
>  return unfinished;
> }{code}
> replace _remove()_ with _removeAll()_



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

[jira] [Closed] (MNG-6370) ConcurrencyDependencyGraph#getNumberOfBuilds() does not remove finished projects from unfinished ones

[Michael Osipov (JIRA)]

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

Michael Osipov closed MNG-6370.
---
   Resolution: Fixed
Fix Version/s: (was: 3.5.4-candidate)
   3.5.4

Fixed with 
[faa9ef0cd3de27d31064f88cd74140516b3569a3|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=faa9ef0cd3de27d31064f88cd74140516b3569a3].

> ConcurrencyDependencyGraph#getNumberOfBuilds() does not remove finished 
> projects from unfinished ones
> -
>
> Key: MNG-6370
> URL: https://issues.apache.org/jira/browse/MNG-6370
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.5.2, 3.5.3
>Reporter: Sylwester Lachiewicz
>Assignee: Michael Osipov
>Priority: Trivial
> Fix For: 3.5.4
>
>
> Fix _ConcurrencyDependencyGraph.getUnfinishedProjects_
> {code:java}
> private final HashSet finishedProjects = new HashSet<>();
> /**
>  * @return set of projects that have yet to be processed successfully by the 
> build.
>  */
> public Set getUnfinishedProjects()
> {
>  Set unfinished = new HashSet<>( projectBuilds.getProjects() );
>  unfinished.remove( finishedProjects );
>  return unfinished;
> }{code}
> replace _remove()_ with _removeAll()_



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

[jira] [Assigned] (MRELEASE-979) Support NamingPolicies to manage Branch and Tag names

[Robert Scholte (JIRA)]

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

Robert Scholte reassigned MRELEASE-979:
---

Assignee: Robert Scholte

> Support NamingPolicies to manage Branch and Tag names
> -
>
> Key: MRELEASE-979
> URL: https://issues.apache.org/jira/browse/MRELEASE-979
> Project: Maven Release Plugin
>  Issue Type: Improvement
>  Components: branch, prepare, update-versions
>Affects Versions: 2.5.3
>Reporter: Henning Schmiedehausen
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.0.0
>
>
> The newly introduced VersionPolicy facility allows managing the development 
> and release versions of projects when releasing, branching and updating 
> versions.
> Most organizations will also have a policy around how branches and tags are 
> named (which often have to match specific versioning patterns). The current 
> VersionPolicy implementations do not allow this but it should be possible.



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

[jira] [Created] (MNG-6372) On Windows with -T option, Maven can output spurios ANSI escapes such as {{[0m [0m}}

[Stephen Connolly (JIRA)]

Stephen Connolly created MNG-6372:
-

 Summary: On Windows with -T option, Maven can output spurios ANSI 
escapes such as {{[0m [0m}}
 Key: MNG-6372
 URL: https://issues.apache.org/jira/browse/MNG-6372
 Project: Maven
  Issue Type: New Feature
Affects Versions: 3.5.3
Reporter: Stephen Connolly


Found during the release vote of Maven 3.5.3

A regression introduced by the upgrade of JAnsi to 1.17. Rumoured fixed in 1.18



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

[jira] [Closed] (MSTAGE-17) copy all dependencies automatically

[Michael Osipov (JIRA)]

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

Michael Osipov closed MSTAGE-17.

Resolution: Invalid

This isn't a support forum.

> copy all dependencies automatically
> ---
>
> Key: MSTAGE-17
> URL: https://issues.apache.org/jira/browse/MSTAGE-17
> Project: Maven Stage Plugin
>  Issue Type: Bug
>Reporter: Hannes Kogler
>Priority: Major
>
> as it seems the dependencies of the artifact are not copied automatically too.
> but thats what the feature of an artifact copy from one repository to another 
> should be?!
> or am I doing anything wrong?



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

[jira] [Closed] (MDEPLOY-232) Using maven-fluido-skin 1.7

[Karl Heinz Marbaise (JIRA)]

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

Karl Heinz Marbaise closed MDEPLOY-232.
---
Resolution: Fixed

Done in 
[030cf8d6fc67e65d83467af24721181223d50bac|https://gitbox.apache.org/repos/asf?p=maven-ear-plugin.git;a=commitdiff;h=030cf8d6fc67e65d83467af24721181223d50bac]

> Using maven-fluido-skin 1.7
> ---
>
> Key: MDEPLOY-232
> URL: https://issues.apache.org/jira/browse/MDEPLOY-232
> Project: Maven Deploy Plugin
>  Issue Type: Improvement
>Affects Versions: 3.0.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.0
>
>




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

[jira] [Commented] (MANT-86) Retire the plugin

[Michael Osipov (JIRA)]

[ 
https://issues.apache.org/jira/browse/MANT-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16390340#comment-16390340
 ] 

Michael Osipov commented on MANT-86:


[~khmarbaise], do you finally want to retire this plugin?

> Retire the plugin
> -
>
> Key: MANT-86
> URL: https://issues.apache.org/jira/browse/MANT-86
> Project: Maven Ant Plugin
>  Issue Type: Wish
>Affects Versions: 3.0
>Reporter: Karl Heinz Marbaise
>Priority: Major
> Fix For: 3.0
>
>
> We should start a VOTE 
> http://maven.apache.org/developers/retirement-plan-plugins.html at the 
> 2015/02/01 to ultimately retire this plugin...



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

[jira] [Assigned] (MRELEASE-985) Override SNAPSHOT dependencies from command line

[Robert Scholte (JIRA)]

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

Robert Scholte reassigned MRELEASE-985:
---

Assignee: Robert Scholte

> Override SNAPSHOT dependencies from command line
> 
>
> Key: MRELEASE-985
> URL: https://issues.apache.org/jira/browse/MRELEASE-985
> Project: Maven Release Plugin
>  Issue Type: New Feature
>Reporter: Petar Tahchiev
>Assignee: Robert Scholte
>Priority: Major
>
> As a user I would like to be able to override SNAPSHOT dependencies from the 
> command line so that the build would not be aborted if I have SNAPSHOT 
> dependencies in my {{pom.xml}}.
> For example let's consider I have a {{pom.xml}} which declares the following 
> dependency:
> {code}
> 
> com.mycompany
> test
> 1.0-SNAPSHOT
> 
> {code}
> or this parent:
> {code}
> 
> com.mycompany
> test
> 1.0-SNAPSHOT
> 
> {code}
> When I start the build it would fail, because I have unresolved SNAPSHOT 
> dependencies. However, it would be really useful if I can specify the 
> following:
> {code}
> mvn release:prepare --batch-mode 
> -DdependencyVersion.com.mycompany:test=1.1.RELEASE 
> -DdevelopmentVersion.com.mycompany:test=1.2.BUILD-SNAPSHOT
> {code}



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

[jira] [Commented] (MNG-6370) ConcurrencyDependencyGraph#getNumberOfBuilds() does not remove finished projects from unfinished ones

[Hudson (JIRA)]

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

Hudson commented on MNG-6370:
-

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

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

> ConcurrencyDependencyGraph#getNumberOfBuilds() does not remove finished 
> projects from unfinished ones
> -
>
> Key: MNG-6370
> URL: https://issues.apache.org/jira/browse/MNG-6370
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.5.2, 3.5.3
>Reporter: Sylwester Lachiewicz
>Assignee: Michael Osipov
>Priority: Trivial
> Fix For: 3.5.4
>
>
> Fix _ConcurrencyDependencyGraph.getUnfinishedProjects_
> {code:java}
> private final HashSet finishedProjects = new HashSet<>();
> /**
>  * @return set of projects that have yet to be processed successfully by the 
> build.
>  */
> public Set getUnfinishedProjects()
> {
>  Set unfinished = new HashSet<>( projectBuilds.getProjects() );
>  unfinished.remove( finishedProjects );
>  return unfinished;
> }{code}
> replace _remove()_ with _removeAll()_



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

[jira] [Updated] (MPH-117) Upgrade plexus-utils to 3.0.22

[JIRA]

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

Hervé Boutemy updated MPH-117:
--
Issue Type: Dependency upgrade  (was: Improvement)

> Upgrade plexus-utils to 3.0.22
> --
>
> Key: MPH-117
> URL: https://issues.apache.org/jira/browse/MPH-117
> Project: Maven Help Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.0
>
>




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

[jira] [Updated] (MPH-102) Upgrade to maven-plugins parent version 27

[JIRA]

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

Hervé Boutemy updated MPH-102:
--
Issue Type: Dependency upgrade  (was: Improvement)

> Upgrade to maven-plugins parent version 27
> --
>
> Key: MPH-102
> URL: https://issues.apache.org/jira/browse/MPH-102
> Project: Maven Help Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.0
>
>
> Upgrade to maven-plugins parent version 27



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

[jira] [Updated] (MPH-118) Upgrade maven-plugins to version 30

[JIRA]

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

Hervé Boutemy updated MPH-118:
--
Issue Type: Dependency upgrade  (was: Improvement)

> Upgrade maven-plugins to version 30
> ---
>
> Key: MPH-118
> URL: https://issues.apache.org/jira/browse/MPH-118
> Project: Maven Help Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.0
>
>




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

[jira] [Updated] (MPH-104) Upgrade maven-plugin-testing-harness to 1.3

[JIRA]

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

Hervé Boutemy updated MPH-104:
--
Issue Type: Dependency upgrade  (was: Improvement)

> Upgrade maven-plugin-testing-harness to 1.3
> ---
>
> Key: MPH-104
> URL: https://issues.apache.org/jira/browse/MPH-104
> Project: Maven Help Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.0
>
>




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

[jira] [Created] (MJAVADOC-517) NPE under Java 10 EA

[Ian Young (JIRA)]

Ian Young created MJAVADOC-517:
--

 Summary: NPE under Java 10 EA
 Key: MJAVADOC-517
 URL: https://issues.apache.org/jira/browse/MJAVADOC-517
 Project: Maven Javadoc Plugin
  Issue Type: Bug
Affects Versions: 3.0.0
Reporter: Ian Young


Under Java 10 EA, the plugin generates the following exception:
{code:java}
Caused by: java.lang.NullPointerException
    at org.apache.commons.lang3.SystemUtils.isJavaVersionAtLeast 
(SystemUtils.java:1626)
    at 
org.apache.maven.plugins.javadoc.AbstractJavadocMojo.getJavadocExecutable 
(AbstractJavadocMojo.java:3683)
    at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.executeReport 
(AbstractJavadocMojo.java:2001)
    at org.apache.maven.plugins.javadoc.JavadocJar.doExecute 
(JavadocJar.java:190)
{code}
This seems to be down to the version string:
{code:java}
java version "10" 2018-03-20
Java(TM) SE Runtime Environment 18.3 (build 10+43)
Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10+43, mixed mode)
{code}
{{commons-lang3}} version 3.5 can't deal with this, see 
https://issues.apache.org/jira/browse/LANG-1365 

Inserting an explicit dependency on {{commons-lang3}} version 3.7 for the 
plugin works round the issue, and seems the right fix for the next release of 
this plugin.



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

[jira] [Updated] (MJAVADOC-517) NPE under Java 10 EA

[Ian Young (JIRA)]

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

Ian Young updated MJAVADOC-517:
---
Description: 
Under Java 10 EA, the plugin generates the following exception:
{code:java}
Caused by: java.lang.NullPointerException
    at org.apache.commons.lang3.SystemUtils.isJavaVersionAtLeast 
(SystemUtils.java:1626)
    at 
org.apache.maven.plugins.javadoc.AbstractJavadocMojo.getJavadocExecutable 
(AbstractJavadocMojo.java:3683)
    at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.executeReport 
(AbstractJavadocMojo.java:2001)
    at org.apache.maven.plugins.javadoc.JavadocJar.doExecute 
(JavadocJar.java:190)
{code}
This seems to be down to the version string:
{code:java}
java version "10" 2018-03-20
Java(TM) SE Runtime Environment 18.3 (build 10+43)
Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10+43, mixed mode)
{code}
{{commons-lang3}} version 3.5 can't deal with this, see 
https://issues.apache.org/jira/browse/LANG-1365 

Inserting an explicit dependency on {{commons-lang3}} version 3.7 for the 
plugin works round the issue, and changing the dependency seems like the right 
fix for the next release of this plugin.

  was:
Under Java 10 EA, the plugin generates the following exception:
{code:java}
Caused by: java.lang.NullPointerException
    at org.apache.commons.lang3.SystemUtils.isJavaVersionAtLeast 
(SystemUtils.java:1626)
    at 
org.apache.maven.plugins.javadoc.AbstractJavadocMojo.getJavadocExecutable 
(AbstractJavadocMojo.java:3683)
    at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.executeReport 
(AbstractJavadocMojo.java:2001)
    at org.apache.maven.plugins.javadoc.JavadocJar.doExecute 
(JavadocJar.java:190)
{code}
This seems to be down to the version string:
{code:java}
java version "10" 2018-03-20
Java(TM) SE Runtime Environment 18.3 (build 10+43)
Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10+43, mixed mode)
{code}
{{commons-lang3}} version 3.5 can't deal with this, see 
https://issues.apache.org/jira/browse/LANG-1365 

Inserting an explicit dependency on {{commons-lang3}} version 3.7 for the 
plugin works round the issue, and seems the right fix for the next release of 
this plugin.


> NPE under Java 10 EA
> 
>
> Key: MJAVADOC-517
> URL: https://issues.apache.org/jira/browse/MJAVADOC-517
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Ian Young
>Priority: Major
>
> Under Java 10 EA, the plugin generates the following exception:
> {code:java}
> Caused by: java.lang.NullPointerException
>     at org.apache.commons.lang3.SystemUtils.isJavaVersionAtLeast 
> (SystemUtils.java:1626)
>     at 
> org.apache.maven.plugins.javadoc.AbstractJavadocMojo.getJavadocExecutable 
> (AbstractJavadocMojo.java:3683)
>     at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.executeReport 
> (AbstractJavadocMojo.java:2001)
>     at org.apache.maven.plugins.javadoc.JavadocJar.doExecute 
> (JavadocJar.java:190)
> {code}
> This seems to be down to the version string:
> {code:java}
> java version "10" 2018-03-20
> Java(TM) SE Runtime Environment 18.3 (build 10+43)
> Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10+43, mixed mode)
> {code}
> {{commons-lang3}} version 3.5 can't deal with this, see 
> https://issues.apache.org/jira/browse/LANG-1365 
> Inserting an explicit dependency on {{commons-lang3}} version 3.7 for the 
> plugin works round the issue, and changing the dependency seems like the 
> right fix for the next release of this plugin.



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

[jira] [Updated] (MJAVADOC-517) NPE under Java 10 RC

[Ian Young (JIRA)]

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

Ian Young updated MJAVADOC-517:
---
Summary: NPE under Java 10 RC  (was: NPE under Java 10 EA)

> NPE under Java 10 RC
> 
>
> Key: MJAVADOC-517
> URL: https://issues.apache.org/jira/browse/MJAVADOC-517
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Ian Young
>Priority: Major
>
> Under Java 10 EA, the plugin generates the following exception:
> {code:java}
> Caused by: java.lang.NullPointerException
>     at org.apache.commons.lang3.SystemUtils.isJavaVersionAtLeast 
> (SystemUtils.java:1626)
>     at 
> org.apache.maven.plugins.javadoc.AbstractJavadocMojo.getJavadocExecutable 
> (AbstractJavadocMojo.java:3683)
>     at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.executeReport 
> (AbstractJavadocMojo.java:2001)
>     at org.apache.maven.plugins.javadoc.JavadocJar.doExecute 
> (JavadocJar.java:190)
> {code}
> This seems to be down to the version string:
> {code:java}
> java version "10" 2018-03-20
> Java(TM) SE Runtime Environment 18.3 (build 10+43)
> Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10+43, mixed mode)
> {code}
> {{commons-lang3}} version 3.5 can't deal with this, see 
> https://issues.apache.org/jira/browse/LANG-1365 
> Inserting an explicit dependency on {{commons-lang3}} version 3.7 for the 
> plugin works round the issue, and changing the dependency seems like the 
> right fix for the next release of this plugin.



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

[jira] [Updated] (MJAVADOC-517) NPE under Java 10 RC

[Ian Young (JIRA)]

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

Ian Young updated MJAVADOC-517:
---
Description: 
Under Java 10 RC, the plugin generates the following exception:
{code:java}
Caused by: java.lang.NullPointerException
    at org.apache.commons.lang3.SystemUtils.isJavaVersionAtLeast 
(SystemUtils.java:1626)
    at 
org.apache.maven.plugins.javadoc.AbstractJavadocMojo.getJavadocExecutable 
(AbstractJavadocMojo.java:3683)
    at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.executeReport 
(AbstractJavadocMojo.java:2001)
    at org.apache.maven.plugins.javadoc.JavadocJar.doExecute 
(JavadocJar.java:190)
{code}
This seems to be down to the version string:
{code:java}
java version "10" 2018-03-20
Java(TM) SE Runtime Environment 18.3 (build 10+43)
Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10+43, mixed mode)
{code}
{{commons-lang3}} version 3.5 can't deal with this, see 
https://issues.apache.org/jira/browse/LANG-1365 

Inserting an explicit dependency on {{commons-lang3}} version 3.7 for the 
plugin works round the issue, and changing the dependency seems like the right 
fix for the next release of this plugin.

  was:
Under Java 10 EA, the plugin generates the following exception:
{code:java}
Caused by: java.lang.NullPointerException
    at org.apache.commons.lang3.SystemUtils.isJavaVersionAtLeast 
(SystemUtils.java:1626)
    at 
org.apache.maven.plugins.javadoc.AbstractJavadocMojo.getJavadocExecutable 
(AbstractJavadocMojo.java:3683)
    at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.executeReport 
(AbstractJavadocMojo.java:2001)
    at org.apache.maven.plugins.javadoc.JavadocJar.doExecute 
(JavadocJar.java:190)
{code}
This seems to be down to the version string:
{code:java}
java version "10" 2018-03-20
Java(TM) SE Runtime Environment 18.3 (build 10+43)
Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10+43, mixed mode)
{code}
{{commons-lang3}} version 3.5 can't deal with this, see 
https://issues.apache.org/jira/browse/LANG-1365 

Inserting an explicit dependency on {{commons-lang3}} version 3.7 for the 
plugin works round the issue, and changing the dependency seems like the right 
fix for the next release of this plugin.


> NPE under Java 10 RC
> 
>
> Key: MJAVADOC-517
> URL: https://issues.apache.org/jira/browse/MJAVADOC-517
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Ian Young
>Priority: Major
>
> Under Java 10 RC, the plugin generates the following exception:
> {code:java}
> Caused by: java.lang.NullPointerException
>     at org.apache.commons.lang3.SystemUtils.isJavaVersionAtLeast 
> (SystemUtils.java:1626)
>     at 
> org.apache.maven.plugins.javadoc.AbstractJavadocMojo.getJavadocExecutable 
> (AbstractJavadocMojo.java:3683)
>     at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.executeReport 
> (AbstractJavadocMojo.java:2001)
>     at org.apache.maven.plugins.javadoc.JavadocJar.doExecute 
> (JavadocJar.java:190)
> {code}
> This seems to be down to the version string:
> {code:java}
> java version "10" 2018-03-20
> Java(TM) SE Runtime Environment 18.3 (build 10+43)
> Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10+43, mixed mode)
> {code}
> {{commons-lang3}} version 3.5 can't deal with this, see 
> https://issues.apache.org/jira/browse/LANG-1365 
> Inserting an explicit dependency on {{commons-lang3}} version 3.7 for the 
> plugin works round the issue, and changing the dependency seems like the 
> right fix for the next release of this plugin.



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

[jira] [Commented] (MRESOURCES-236) Copying of files with permissions broken

[Markus Rathgeb (JIRA)]

[ 
https://issues.apache.org/jira/browse/MRESOURCES-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16389242#comment-16389242
 ] 

Markus Rathgeb commented on MRESOURCES-236:
---

Bug still present in Maven Resource Plugin Version 3.0.2

> Copying of files with permissions broken
> 
>
> Key: MRESOURCES-236
> URL: https://issues.apache.org/jira/browse/MRESOURCES-236
> Project: Maven Resources Plugin
>  Issue Type: Bug
>  Components: copy
>Affects Versions: 2.4.3
>Reporter: Gili
>Priority: Major
>
> Please reopen MRESOURCES-132 as multiple reporters indicate that the bug 
> still exists (some provided more concrete repro steps).



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

[jira] [Commented] (SUREFIRE-1422) Forking fails on Linux if /bin/ps isn't available

[Tibor Digana (JIRA)]

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

Tibor Digana commented on SUREFIRE-1422:


Let's start from the beginning.
What is your scenario?
I guess it is scenario where you run Maven build in Docker, the tests run
as well and something kills Maven process within the Docker. You expect the
surefire JVM to be killed right after? Am I right?

On Wed, Mar 7, 2018 at 10:58 AM, Thomas Raehalme (JIRA) 



> Forking fails on Linux if /bin/ps isn't available
> -
>
> Key: SUREFIRE-1422
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1422
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: process forking
>Affects Versions: 2.20.1
> Environment: Linux (Debian 9 with OpenJDK 8)
>Reporter: Emmanuel Bourg
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.21.0
>
>
> Hi,
> With the changes introduced by SUREFIRE-1302 I'm now experiencing a failure 
> on Linux when the fork mode is enabled:
> {code}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test (default-test) on 
> project foo: There are test failures.
> [ERROR]
> [ERROR] Please refer to /foo/target/surefire-reports for the individual test 
> results.
> [ERROR] Please refer to dump files (if any exist) [date]-jvmRun[N].dump, 
> [date].dumpstream and [date]-jvmRun[N].dumpstream.
> [ERROR] The forked VM terminated without properly saying goodbye. VM crash or 
> System.exit called?
> {code}
> I traced the issue back to the PpidChecker class, the code assumes that 
> {{/bin/ps}} or {{/usr/bin/ps}} exist but this isn't guaranteed (especially on 
> trimmed down containers commonly used for continuous integration).
> It would be nice to have a fallback mechanism when ps isn't available, or at 
> least check its existence and display an explicit message stating that it 
> must be installed.



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

[jira] [Commented] (SUREFIRE-1422) Forking fails on Linux if /bin/ps isn't available

[Thomas Raehalme (JIRA)]

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

Thomas Raehalme commented on SUREFIRE-1422:
---

Yes, the process is killed which was the original problem :)

> Forking fails on Linux if /bin/ps isn't available
> -
>
> Key: SUREFIRE-1422
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1422
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: process forking
>Affects Versions: 2.20.1
> Environment: Linux (Debian 9 with OpenJDK 8)
>Reporter: Emmanuel Bourg
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.21.0
>
>
> Hi,
> With the changes introduced by SUREFIRE-1302 I'm now experiencing a failure 
> on Linux when the fork mode is enabled:
> {code}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test (default-test) on 
> project foo: There are test failures.
> [ERROR]
> [ERROR] Please refer to /foo/target/surefire-reports for the individual test 
> results.
> [ERROR] Please refer to dump files (if any exist) [date]-jvmRun[N].dump, 
> [date].dumpstream and [date]-jvmRun[N].dumpstream.
> [ERROR] The forked VM terminated without properly saying goodbye. VM crash or 
> System.exit called?
> {code}
> I traced the issue back to the PpidChecker class, the code assumes that 
> {{/bin/ps}} or {{/usr/bin/ps}} exist but this isn't guaranteed (especially on 
> trimmed down containers commonly used for continuous integration).
> It would be nice to have a fallback mechanism when ps isn't available, or at 
> least check its existence and display an explicit message stating that it 
> must be installed.



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

[jira] [Commented] (SUREFIRE-1422) Forking fails on Linux if /bin/ps isn't available

[Tibor Digana (JIRA)]

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

Tibor Digana commented on SUREFIRE-1422:


Ok, I will compare these two versions.
If the command fails then the default mechanism should take over and forked
JVM would be killed till 30 seconds.
Does it behave like that?

On Wed, Mar 7, 2018 at 6:05 AM, Andrew Potter (JIRA) 



> Forking fails on Linux if /bin/ps isn't available
> -
>
> Key: SUREFIRE-1422
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1422
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: process forking
>Affects Versions: 2.20.1
> Environment: Linux (Debian 9 with OpenJDK 8)
>Reporter: Emmanuel Bourg
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.21.0
>
>
> Hi,
> With the changes introduced by SUREFIRE-1302 I'm now experiencing a failure 
> on Linux when the fork mode is enabled:
> {code}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test (default-test) on 
> project foo: There are test failures.
> [ERROR]
> [ERROR] Please refer to /foo/target/surefire-reports for the individual test 
> results.
> [ERROR] Please refer to dump files (if any exist) [date]-jvmRun[N].dump, 
> [date].dumpstream and [date]-jvmRun[N].dumpstream.
> [ERROR] The forked VM terminated without properly saying goodbye. VM crash or 
> System.exit called?
> {code}
> I traced the issue back to the PpidChecker class, the code assumes that 
> {{/bin/ps}} or {{/usr/bin/ps}} exist but this isn't guaranteed (especially on 
> trimmed down containers commonly used for continuous integration).
> It would be nice to have a fallback mechanism when ps isn't available, or at 
> least check its existence and display an explicit message stating that it 
> must be installed.



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

[jira] [Commented] (SUREFIRE-1422) Forking fails on Linux if /bin/ps isn't available

[Thomas Raehalme (JIRA)]

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

Thomas Raehalme commented on SUREFIRE-1422:
---

The problem is that even though the tests run just fine, the forked process is 
killed (by Maven) and the build therefore fails.

In your previous comment you state that "if the command fails then the default 
mechanism should take over and forked JVM would be killed till 30 seconds". 
Because Alpine by default does not support the -p flag, this always happens, 
and is a problem if the tests run longer than 30 seconds, right?

> Forking fails on Linux if /bin/ps isn't available
> -
>
> Key: SUREFIRE-1422
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1422
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: process forking
>Affects Versions: 2.20.1
> Environment: Linux (Debian 9 with OpenJDK 8)
>Reporter: Emmanuel Bourg
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.21.0
>
>
> Hi,
> With the changes introduced by SUREFIRE-1302 I'm now experiencing a failure 
> on Linux when the fork mode is enabled:
> {code}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test (default-test) on 
> project foo: There are test failures.
> [ERROR]
> [ERROR] Please refer to /foo/target/surefire-reports for the individual test 
> results.
> [ERROR] Please refer to dump files (if any exist) [date]-jvmRun[N].dump, 
> [date].dumpstream and [date]-jvmRun[N].dumpstream.
> [ERROR] The forked VM terminated without properly saying goodbye. VM crash or 
> System.exit called?
> {code}
> I traced the issue back to the PpidChecker class, the code assumes that 
> {{/bin/ps}} or {{/usr/bin/ps}} exist but this isn't guaranteed (especially on 
> trimmed down containers commonly used for continuous integration).
> It would be nice to have a fallback mechanism when ps isn't available, or at 
> least check its existence and display an explicit message stating that it 
> must be installed.



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

[GitHub] dmlloyd commented on issue #1: [MCOMPILER-320] Introduce additionalClasspathElements property

[GitBox]

dmlloyd commented on issue #1: [MCOMPILER-320] Introduce 
additionalClasspathElements property
URL: 
https://github.com/apache/maven-compiler-plugin/pull/1#issuecomment-371153600
 
 
   Any updates on this? @rfscholte ?


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-320) Allow additional class path items to be given during compilation

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MCOMPILER-320:
--

dmlloyd commented on issue #1: [MCOMPILER-320] Introduce 
additionalClasspathElements property
URL: 
https://github.com/apache/maven-compiler-plugin/pull/1#issuecomment-371153600
 
 
   Any updates on this? @rfscholte ?


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


> Allow additional class path items to be given during compilation
> 
>
> Key: MCOMPILER-320
> URL: https://issues.apache.org/jira/browse/MCOMPILER-320
> Project: Maven Compiler Plugin
>  Issue Type: New Feature
>Reporter: David M. Lloyd
>Priority: Major
> Fix For: 3.7.1
>
>
> At present it is very difficult to include additional class path items during 
> compilation that are not dependencies.  But this is a very useful capability, 
> especially when doing partial builds, MR JARs, JDK API stubbing, including 
> dependency items that cannot be included in any other build phase or 
> execution, etc.
> This enhancement and pull request are to request the addition of a 
> {{additionalCompilePathItems}} property in CompilerMojo or 
> AbstractCompilerMojo which includes additional filesystem paths in the 
> compilation class path.



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

[jira] [Commented] (SUREFIRE-1422) Forking fails on Linux if /bin/ps isn't available

[Tibor Digana (JIRA)]

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

Tibor Digana commented on SUREFIRE-1422:


Maven process sends NOOP event every 10 seconds (longer because of GC
period may take several seconds on large Heap).
A Thread counts every NOOP. If NOOP has not been received after 3
successive periods (30 seconds) then the forked JVM kills itself.
This is an old mechanism which is disabled if new mechanism (ps -p ...) do
not fail. The new mechanism checks the e-time of PPID (means Maven process)
every single second. If the output of the command is empty it means the
Maven finished and the forked JVM will kill itself. If the e-time is
suddenly smaller it means the PPID is reused and again the fork will be
killed.

On Wed, Mar 7, 2018 at 11:28 AM, Thomas Raehalme (JIRA) 



> Forking fails on Linux if /bin/ps isn't available
> -
>
> Key: SUREFIRE-1422
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1422
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: process forking
>Affects Versions: 2.20.1
> Environment: Linux (Debian 9 with OpenJDK 8)
>Reporter: Emmanuel Bourg
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.21.0
>
>
> Hi,
> With the changes introduced by SUREFIRE-1302 I'm now experiencing a failure 
> on Linux when the fork mode is enabled:
> {code}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test (default-test) on 
> project foo: There are test failures.
> [ERROR]
> [ERROR] Please refer to /foo/target/surefire-reports for the individual test 
> results.
> [ERROR] Please refer to dump files (if any exist) [date]-jvmRun[N].dump, 
> [date].dumpstream and [date]-jvmRun[N].dumpstream.
> [ERROR] The forked VM terminated without properly saying goodbye. VM crash or 
> System.exit called?
> {code}
> I traced the issue back to the PpidChecker class, the code assumes that 
> {{/bin/ps}} or {{/usr/bin/ps}} exist but this isn't guaranteed (especially on 
> trimmed down containers commonly used for continuous integration).
> It would be nice to have a fallback mechanism when ps isn't available, or at 
> least check its existence and display an explicit message stating that it 
> must be installed.



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

[jira] [Created] (SUREFIRE-1497) Flag to select modulepath or classpath

[Stephen Colebourne (JIRA)]

Stephen Colebourne created SUREFIRE-1497:


 Summary: Flag to select modulepath or classpath
 Key: SUREFIRE-1497
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1497
 Project: Maven Surefire
  Issue Type: Improvement
Reporter: Stephen Colebourne


SUREFIRE-1262 added the ability to run tests using the modulepath, which is 
great. However, as a library developer I cannot guarantee that the code will be 
run on the modulepath, it might well be run on the classpath.

As such, can I request a flag that turns the behaviour in SUREFIRE-1262 on and 
off? This would allow a single pom.xml to run surefire twice, once with the 
code on the modulepath and once with the code on the classpath, to ensure that 
the behaviour always works however the code is run. (Other solutions to achieve 
the same goal may be possible, but this seems the most obvious).



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

[jira] [Created] (SUREFIRE-1496) Dump file error for java.lang.module.ResolutionException

[Stephen Colebourne (JIRA)]

Stephen Colebourne created SUREFIRE-1496:


 Summary: Dump file error for java.lang.module.ResolutionException
 Key: SUREFIRE-1496
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1496
 Project: Maven Surefire
  Issue Type: Bug
  Components: process forking
Affects Versions: 2.21.0
Reporter: Stephen Colebourne


Scenario:
 * two JPMS modules `org.foo.a` and `org.foo.b`, both with module-info
 * `org.foo.a` requires `org.foo.b`
 * `org.foo.b` exports package `org.foo.b.c`
 * `org.foo.a` contains a text file: src/main/resources/org/foo/b/c/Foo.txt
 * when surefire is run on module `org.foo.a` a dump file error occurs:

 
{noformat}
Corrupted STDOUT by directly writing to native stream in forked JVM 1. Stream 
'Error occurred during initialization of boot layer'.
java.lang.IllegalArgumentException: Stream stdin corrupted. Expected comma 
after third character in command 'Error occurred during initialization of boot 
layer'.
 at 
org.apache.maven.plugin.surefire.booterclient.output.ForkClient$OperationalData.(ForkClient.java:511)
 at 
org.apache.maven.plugin.surefire.booterclient.output.ForkClient.processLine(ForkClient.java:209)
 at 
org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:176)
 at 
org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:88)
 at java.base/java.lang.Thread.run(Thread.java:844)
Created on 2018-03-07T11:32:36.053
Corrupted STDOUT by directly writing to native stream in forked JVM 1. Stream 
'java.lang.module.ResolutionException: Module org.foo.a contains package 
org.foo.b.c, module org.foo.b exports package org.foo.b.c to org.foo.a'. 
{noformat}
 

While the scenario is one that JPMS rejects, surefire should handle it better. 
The compiler compiles the code just fine because it doesn't see the resources 
as a package. Surefire is thus the first part of Maven that sees it as a 
"package" that clashes with the module org.foo.b.

Clearly, some part of surefire needs to be taught to about 
java.lang.module.ResolutionException, as the error is tricky to find/see 
because it is a dump file.

 



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

[jira] [Updated] (SUREFIRE-1497) Flag to select modulepath or classpath

[Stephen Colebourne (JIRA)]

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

Stephen Colebourne updated SUREFIRE-1497:
-
Affects Version/s: 2.21.0

> Flag to select modulepath or classpath
> --
>
> Key: SUREFIRE-1497
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1497
> Project: Maven Surefire
>  Issue Type: Improvement
>Affects Versions: 2.21.0
>Reporter: Stephen Colebourne
>Priority: Major
>
> SUREFIRE-1262 added the ability to run tests using the modulepath, which is 
> great. However, as a library developer I cannot guarantee that the code will 
> be run on the modulepath, it might well be run on the classpath.
> As such, can I request a flag that turns the behaviour in SUREFIRE-1262 on 
> and off? This would allow a single pom.xml to run surefire twice, once with 
> the code on the modulepath and once with the code on the classpath, to ensure 
> that the behaviour always works however the code is run. (Other solutions to 
> achieve the same goal may be possible, but this seems the most obvious).



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

[jira] [Commented] (SUREFIRE-1422) Forking fails on Linux if /bin/ps isn't available

[Andrew Potter (JIRA)]

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

Andrew Potter commented on SUREFIRE-1422:
-

In my case, the tests fail to run immediately with 2.21.0, and they pass with 
2.19.1 in the same container.  The error is the same as the OP:
{code:java}
The forked VM terminated without properly saying goodbye. VM crash or 
System.exit called?
{code}

> Forking fails on Linux if /bin/ps isn't available
> -
>
> Key: SUREFIRE-1422
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1422
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: process forking
>Affects Versions: 2.20.1
> Environment: Linux (Debian 9 with OpenJDK 8)
>Reporter: Emmanuel Bourg
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.21.0
>
>
> Hi,
> With the changes introduced by SUREFIRE-1302 I'm now experiencing a failure 
> on Linux when the fork mode is enabled:
> {code}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test (default-test) on 
> project foo: There are test failures.
> [ERROR]
> [ERROR] Please refer to /foo/target/surefire-reports for the individual test 
> results.
> [ERROR] Please refer to dump files (if any exist) [date]-jvmRun[N].dump, 
> [date].dumpstream and [date]-jvmRun[N].dumpstream.
> [ERROR] The forked VM terminated without properly saying goodbye. VM crash or 
> System.exit called?
> {code}
> I traced the issue back to the PpidChecker class, the code assumes that 
> {{/bin/ps}} or {{/usr/bin/ps}} exist but this isn't guaranteed (especially on 
> trimmed down containers commonly used for continuous integration).
> It would be nice to have a fallback mechanism when ps isn't available, or at 
> least check its existence and display an explicit message stating that it 
> must be installed.



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

[jira] [Created] (MASSEMBLY-879) useDefaultExcludes has no effect in dependencySet/unpack

[Edwin van der Ham (JIRA)]

Edwin van der Ham created MASSEMBLY-879:
---

 Summary: useDefaultExcludes has no effect in dependencySet/unpack
 Key: MASSEMBLY-879
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-879
 Project: Maven Assembly Plugin
  Issue Type: Bug
  Components: dependencySet
Affects Versions: 3.1.0
Reporter: Edwin van der Ham


I have the following dependencySet: 
{code:java}

  false
  
some-artifact:of-type-zip
  
  MyOutputDir
  true
  
false
  
  runtime

{code}
The zip artifact included here contains some files and also a .gitignore file. 
No matter how hard I try, but I cannot get the unpacker to also unpack the 
.gitignore file on my Jenkins build server. It is running CentOS and maven 
3.3.3. On my windows machine, running maven 3.5.2 it will always include the 
.gitignore, even if I set the value of useDefaultExcludes to true.

So it seems that the useDefaultExcludes is simply ignored when used inside the 
unpackOptions



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