[jira] [Commented] (SUREFIRE-1422) Forking fails on Linux if /bin/ps isn't available
[ 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
[ 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
[ 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 --helpdisplay 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
[ 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 --helpdisplay 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
[ 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
[ 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 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
[ 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
[ 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
[ 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 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
[ 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 --helpdisplay 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
[ 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
[ 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
[ 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
[ 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 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
[ 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
[ 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
[ 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
[ 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!
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
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
[ 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
[ 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 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 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
[ 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
[ 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 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)