[jira] [Created] (ARCHETYPE-583) Skip parent non-archetype project when updating local catalog

[Lukasz Lenart (Jira)]

Lukasz Lenart created ARCHETYPE-583:
---

 Summary: Skip parent non-archetype project when updating local 
catalog
 Key: ARCHETYPE-583
 URL: https://issues.apache.org/jira/browse/ARCHETYPE-583
 Project: Maven Archetype
  Issue Type: Improvement
  Components: Plugin
Affects Versions: 3.1.2
Reporter: Lukasz Lenart


I'm working on a set of [Struts 
archetypes|https://github.com/apache/struts-archetypes/pull/3] and discovered 
that the parent non-archetype project is also added to the local catalog when 
using {{archetype:update-local-catalog}} goal.

All the submodules are using {{maven-archetype}} 
[packaging|https://maven.apache.org/archetype/archetype-packaging/]  and the 
main project is using {{pom}} packaging.

I have prepared a PR to skip those non-archetype projects
https://github.com/apache/maven-archetype/pull/33



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-surefire] Col-E commented on issue #252: [SUREFIRE-1711] Support @ParameterizedTest for JUnit 5 test reruns

[GitBox]

Col-E commented on issue #252: [SUREFIRE-1711] Support @ParameterizedTest for 
JUnit 5 test reruns
URL: https://github.com/apache/maven-surefire/pull/252#issuecomment-552738991
 
 
   Sorry about not finishing everything up, my schedule should be clearing up 
for a bit soon for future contributions.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [maven-surefire] Tibor17 commented on issue #252: [SUREFIRE-1711] Support @ParameterizedTest for JUnit 5 test reruns

[GitBox]

Tibor17 commented on issue #252: [SUREFIRE-1711] Support @ParameterizedTest for 
JUnit 5 test reruns
URL: https://github.com/apache/maven-surefire/pull/252#issuecomment-552713741
 
 
   @Col-E 
   I fixed the issue with unique test representation in 
https://issues.apache.org/jira/browse/SUREFIRE-1716
   Thx for your effort.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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] [Updated] (SUREFIRE-1716) JUnit5 Parameterized tests and re-run should see unique test runs with different parameters

[Tibor Digana (Jira)]

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

Tibor Digana updated SUREFIRE-1716:
---
Labels: junit5  (was: )

> JUnit5 Parameterized tests and re-run should see unique test runs with 
> different parameters
> ---
>
> Key: SUREFIRE-1716
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1716
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: JUnit 5.x support
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
>  Labels: junit5
> Fix For: 3.0.0-M4
>
>
> The test method has one name and several parameters but the XML reporter 
> should see them as different test method runs.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (SUREFIRE-1716) JUnit5 Parameterized tests and re-run should see unique test runs with different parameters

[Tibor Digana (Jira)]

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

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

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

> JUnit5 Parameterized tests and re-run should see unique test runs with 
> different parameters
> ---
>
> Key: SUREFIRE-1716
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1716
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: JUnit 5.x support
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M4
>
>
> The test method has one name and several parameters but the XML reporter 
> should see them as different test method runs.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (SUREFIRE-1716) JUnit5 Parameterized tests and re-run should see unique test runs with different parameters

[Tibor Digana (Jira)]

Tibor Digana created SUREFIRE-1716:
--

 Summary: JUnit5 Parameterized tests and re-run should see unique 
test runs with different parameters
 Key: SUREFIRE-1716
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1716
 Project: Maven Surefire
  Issue Type: Bug
  Components: JUnit 5.x support
Reporter: Tibor Digana
Assignee: Tibor Digana
 Fix For: 3.0.0-M4


The test method has one name and several parameters but the XML reporter should 
see them as different test method runs.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ

[Tibor Digana (Jira)]

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

Tibor Digana commented on SUREFIRE-1631:


Sorry i was working on several issues in parallel.
I will provide the fix during the day.

> Forked VM terminated without properly saying goodbye with AciveMQ
> -
>
> Key: SUREFIRE-1631
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1631
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20.1, 2.22.0, 3.0.0-M2, 3.0.0-M1
>Reporter: Aaron Digulla
>Assignee: Tibor Digana
>Priority: Major
> Attachments: cmd.PNG, cmd2.PNG, shurefire-shutdownhook-bug-0.0.1.zip
>
>
> I'm seeing spurious "The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?" messages when running unit tests in 
> a big multi-module project.
> OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of 
> Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191.
> I'm running Maven from the command line using MinTTY (Cygwin).
> Things I tried which have no effect:
>  * Reboot / Cold boot (happens first thing on Monday morning when I come into 
> the office and turn on my PC).
>  * More free memory (happens when I only have a single window open). I have 
> 16GB of RAM.
>  * Different terminal. I tried CMD prompt and urxvt (Cygwin/X).
>  * Different versions of the Surefire plugin or Maven
>  * Different JDK 8 builds
> Things that affect the bug:
>  * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log
>  * Redirecting all log output to a file using logback-test.xml
>  * Running Surefire with forkCount=0
>  * Running a subset of the tests (-Dtest=...)
>  * Pending Windows updates (I think, not sure about this one).
> Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never 
> seen it with redirecting log output (~ 10 builds). Redirecting sometimes 
> helps but not always.
> One thing which I notice is that one of the tests creates an ActiveMQ broker 
> and uses a shutdown hook to stop it. So I created a small test project which 
> demonstrates that Surefire will sometimes cut off stdout. I think that 
> happens because the main process kills the child after a timeout (correct?).
> So my guess would be that shutdown hooks can mess with the pipeline between 
> the surefire child VM and main Maven process. ActiveMQ might be worse since 
> it stops threads and execution pools (so the output comes slowly with a 
> couple of exceptions sprinkled in when one component loses connection because 
> another is shutting down).
> But now, it gets weird. When the build succeeds, it takes about ~5 minutes to 
> run 1028 tests. The log is 25 MB.
> When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) 
> and the log stops in the middle of a test but is also 25 MB.
> Some of the time discrepancy is probably because writing to a file is faster 
> than printing on a terminal. The strange part is that the log file is about 
> the same size but 30% of the tests haven't run. Most tests log a lot, do I 
> would expect to see a difference of at least a few MB. The Maven part (which 
> contains escape sequences, etc). is just 60 KB.
> Maybe the parent takes some part of the log output as "child terminated".
> I'm running out of ideas what to try next. I think a way to log the 
> communication between parent and child would help. Also the parent should 
> terminate the child and then read stdout until EOF to we can see anything 
> that happens afterwards.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-surefire] Tibor17 commented on issue #253: Fixes [SUREFIRE-1516]: Poor performance in reuseForks=false

[GitBox]

Tibor17 commented on issue #253: Fixes [SUREFIRE-1516]: Poor performance in 
reuseForks=false
URL: https://github.com/apache/maven-surefire/pull/253#issuecomment-552700580
 
 
   The build fails on macOS.
   `ForkModeMultiModuleIT.testForkCountTwoNoReuse:70->doTest:137 » 
SurefireVerifier`
   Can you pls have a look?
   
https://github.com/apache/maven-surefire/pull/253/checks?check_run_id=298330219


This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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] (MDEP-649) dependency:resolve-plugins lacks includeParents user property

[Nick Stolwijk (Jira)]

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

Nick Stolwijk commented on MDEP-649:


I'm taking a shot at this.

 

Question: is it feasible to do something on [3]? I don't think changing the 
default is a good idea and I think that having the same defaults for the same 
options is a good idea. (Yes, that speaks against itself)

> dependency:resolve-plugins lacks includeParents user property
> -
>
> Key: MDEP-649
> URL: https://issues.apache.org/jira/browse/MDEP-649
> Project: Maven Dependency Plugin
>  Issue Type: New Feature
>  Components: resolve-plugins
>Affects Versions: 3.1.1
>Reporter: Dennis Schridde
>Priority: Major
>
> `dependency:resolve` has an `includeParents` user property [1] which 
> `dependency:resolve-plugins` is lacking [2]. This makes it difficult to 
> generate a complete list of all (JARs and) POMs required to build a project 
> (with dependencies and plugins and their dependencies).
> P.S. `dependency:get` appears to have a similar shortcoming: It can resolve 
> dependencies recursively (`{{transitive}}=true`, enabled by default [3]), but 
> it lacks a `{{includeParents}}` user property.
> [1]: 
> [https://maven.apache.org/plugins/maven-dependency-plugin/resolve-mojo.html#includeParents]
> [2]: 
> [https://maven.apache.org/plugins/maven-dependency-plugin/resolve-plugins-mojo.html]
> [3]: Which BTW is inverse to the disabled-by-default `{{excludeTransitive}}` 
> user property of `dependency:resolve`
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (WAGON-574) improve license management when distributing Wagon shaded binary

[Herve Boutemy (Jira)]

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

Herve Boutemy updated WAGON-574:

Fix Version/s: 3.4.0

> improve license management when distributing Wagon shaded binary
> 
>
> Key: WAGON-574
> URL: https://issues.apache.org/jira/browse/WAGON-574
> Project: Maven Wagon
>  Issue Type: New Feature
>  Components: wagon-http
>Affects Versions: 2.5, 2.6, 2.7, 2.8, 2.9, 2.10, 2.11, 2.12, 3.0.0, 3.1.0, 
> 3.2.0, 3.3.0, 3.3.1, 3.3.2, 3.3.3, 3.3.4
>Reporter: Herve Boutemy
>Priority: Major
> Fix For: 3.4.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> as discussed during Wagon 3.3.4 release vote 
> https://lists.apache.org/thread.html/7526295d1eb080d8d573cfcc2fe4c006c0d948287da7163cc85eadff@%3Cdev.maven.apache.org%3E
>  , 
> wagon-http-3.3.4-shaded.jar includes jsoup, which is MIT licensed
> this should be advertised (since wagon 2.5...)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-surefire] jon-bell opened a new pull request #253: Fixes [SUREFIRE-1516]: Poor performance in reuseForks=false

[GitBox]

jon-bell opened a new pull request #253: Fixes [SUREFIRE-1516]: Poor 
performance in reuseForks=false
URL: https://github.com/apache/maven-surefire/pull/253
 
 
   Hi,
   This PR resolves the performance bug noted in 
[SUREFIRE-1516](https://issues.apache.org/jira/browse/SUREFIRE-1516), which 
appears when using the `reuseForks=false` configuration. The root-cause of the 
observed performance problem comes from forked JVM teardown time.
   
   The issue is that the forked JVM should not block reading IO to read more 
from the host JVM after it sends BYE_ACK. Threads blocking on `read` may not be 
interruptable until they poll for interrupts (every 350msec for stdin), which 
can introduce significant latency for short-lived processes, such as surefire 
forked JVMs which are running just a single test at a time. This 350msec 
overhead can add up on projects that have thousands of test classes, each of 
which might take only several hundred msec to run.
   
   To measure the scope of the problem and confirm its resolution, I created a 
simple benchmark test suite, which consists of 100 JUnit test classes, each 
with a single test that calls `Thread.sleep(250)`. I instrumented the JVM to 
record the time that each JVM starts, the time that the test starts (as 
measured by JUnit), the time that the test ends (as measured by JUnit), and the 
time that the JVM terminates. For comparison, I also did the same experiment 
with ant and gradle.
   
   The table below shows the results, which represent the average time for each 
test (over the 100 samples):
   
   **Configuration**|**Time to start forked JVM**|**Time to run test**|**Time 
to tear down forked JVM**
   :-:|:-:|:-:|:-:
   ant 1.10.6|250.42|252.81|8.75
   gradle 5.6.1|394.91|253.12|16.9
   mvn (b97df5a)|250.21|252.59|358.59
   mvn (2fbe44f)|216.66|252.32|16.9
   
   Overall, most build systems took similar amounts of time to spin up the JVM, 
and all took the expected 250ms to run each test. You can see that the current 
`master` version of surefire (b97df5a) takes an unusually high amount of time 
to tear down the forked JVM (in fact, 350 msec more, which is exactly the time 
for the JVM to interrupt a thread reading from `stdin` [explained in this 
fantastic Stack Overflow 
post]((https://stackoverflow.com/questions/48951611/blocking-on-stdin-makes-java-process-take-350ms-more-to-exit))).
 This is an easy fix though: after receiving the `BYE_ACK` message, the forked 
JVM can stop reading commands from the main surefire process, since it's 
shutting down. After implementing this fix, the overhead goes away (as shown in 
2fbe44f).
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ

[Adolfo Cia (Jira)]

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

Adolfo Cia commented on SUREFIRE-1631:
--

[~tibordigana]

Any news? thanks

> Forked VM terminated without properly saying goodbye with AciveMQ
> -
>
> Key: SUREFIRE-1631
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1631
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20.1, 2.22.0, 3.0.0-M2, 3.0.0-M1
>Reporter: Aaron Digulla
>Assignee: Tibor Digana
>Priority: Major
> Attachments: cmd.PNG, cmd2.PNG, shurefire-shutdownhook-bug-0.0.1.zip
>
>
> I'm seeing spurious "The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?" messages when running unit tests in 
> a big multi-module project.
> OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of 
> Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191.
> I'm running Maven from the command line using MinTTY (Cygwin).
> Things I tried which have no effect:
>  * Reboot / Cold boot (happens first thing on Monday morning when I come into 
> the office and turn on my PC).
>  * More free memory (happens when I only have a single window open). I have 
> 16GB of RAM.
>  * Different terminal. I tried CMD prompt and urxvt (Cygwin/X).
>  * Different versions of the Surefire plugin or Maven
>  * Different JDK 8 builds
> Things that affect the bug:
>  * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log
>  * Redirecting all log output to a file using logback-test.xml
>  * Running Surefire with forkCount=0
>  * Running a subset of the tests (-Dtest=...)
>  * Pending Windows updates (I think, not sure about this one).
> Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never 
> seen it with redirecting log output (~ 10 builds). Redirecting sometimes 
> helps but not always.
> One thing which I notice is that one of the tests creates an ActiveMQ broker 
> and uses a shutdown hook to stop it. So I created a small test project which 
> demonstrates that Surefire will sometimes cut off stdout. I think that 
> happens because the main process kills the child after a timeout (correct?).
> So my guess would be that shutdown hooks can mess with the pipeline between 
> the surefire child VM and main Maven process. ActiveMQ might be worse since 
> it stops threads and execution pools (so the output comes slowly with a 
> couple of exceptions sprinkled in when one component loses connection because 
> another is shutting down).
> But now, it gets weird. When the build succeeds, it takes about ~5 minutes to 
> run 1028 tests. The log is 25 MB.
> When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) 
> and the log stops in the middle of a test but is also 25 MB.
> Some of the time discrepancy is probably because writing to a file is faster 
> than printing on a terminal. The strange part is that the log file is about 
> the same size but 30% of the tests haven't run. Most tests log a lot, do I 
> would expect to see a difference of at least a few MB. The Maven part (which 
> contains escape sequences, etc). is just 60 KB.
> Maybe the parent takes some part of the log output as "child terminated".
> I'm running out of ideas what to try next. I think a way to log the 
> communication between parent and child would help. Also the parent should 
> terminate the child and then read stdout until EOF to we can see anything 
> that happens afterwards.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MEAR-194) Output during creation of Ear is not correct

[Karl Heinz Marbaise (Jira)]

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

Karl Heinz Marbaise updated MEAR-194:
-
Fix Version/s: (was: 3.0.2)
   3.0.3

> Output during creation of Ear is not correct
> 
>
> Key: MEAR-194
> URL: https://issues.apache.org/jira/browse/MEAR-194
> Project: Maven Ear Plugin
>  Issue Type: Improvement
>Affects Versions: 2.9.1
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.3
>
>
> Currently during the creation of the ear the output shows something like this:
> {code}
> [INFO] Building jar: /opt/build/.../xyz-1.0.0-SNAPSHOT.ear
> {code}
> It should be changed into:
> {code}
> [INFO] Building ear: /opt/build/.../xyz-1.0.0-SNAPSHOT.ear
> {code}
> which is more consistent.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MEAR-276) Upgrade maven-archiver to 3.4.0

[Karl Heinz Marbaise (Jira)]

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

Karl Heinz Marbaise updated MEAR-276:
-
Fix Version/s: (was: 3.0.2)
   3.0.3

> Upgrade maven-archiver to 3.4.0
> ---
>
> Key: MEAR-276
> URL: https://issues.apache.org/jira/browse/MEAR-276
> Project: Maven Ear Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.2
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.3
>
>
> 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[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.2)
   3.0.3

> 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.3
>
> 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
(v8.3.4#803005)

[jira] [Updated] (MWAR-415) ${maven.build.timestamp} is not working in filtered webResources

[Robert Scholte (Jira)]

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

Robert Scholte updated MWAR-415:

Description: 
It may be related to MRESOURCES-99

When a webResource, with filtering enabled contains property 
${maven.build.timestamp}, it's not replaced by the timestamp.

The workaround is to remove definitions of webResource and configure the 
resources on  level (and making sure that 
maven-resource-plugin version is >= 3.0.0)

  was:
It may be related to https://issues.apache.org/jira/browse/MRESOURCES-99

When a webResource, with filtering enabled contains property 
${maven.build.timestamp}, it's not replaced by the timestamp.

The workaround is to remove definitions of webResource and configure the 
resources on  level (and making sure that 
maven-resource-plugin version is >= 3.0.0)


> ${maven.build.timestamp} is not working in filtered webResources
> 
>
> Key: MWAR-415
> URL: https://issues.apache.org/jira/browse/MWAR-415
> Project: Maven WAR Plugin
>  Issue Type: Bug
>Affects Versions: 3.2.0
>Reporter: Leonid Rozenblyum
>Priority: Major
>
> It may be related to MRESOURCES-99
> When a webResource, with filtering enabled contains property 
> ${maven.build.timestamp}, it's not replaced by the timestamp.
> The workaround is to remove definitions of webResource and configure the 
> resources on  level (and making sure that 
> maven-resource-plugin version is >= 3.0.0)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-archetype] lukaszlenart opened a new pull request #33: Allow skip non-archetypes

[GitBox]

lukaszlenart opened a new pull request #33: Allow skip non-archetypes
URL: https://github.com/apache/maven-archetype/pull/33
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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] [Closed] (MWAR-340) is ignored by war:exploded

[Robert Scholte (Jira)]

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

Robert Scholte closed MWAR-340.
---
  Assignee: Robert Scholte
Resolution: Duplicate

>  is ignored by war:exploded
> --
>
> Key: MWAR-340
> URL: https://issues.apache.org/jira/browse/MWAR-340
> Project: Maven WAR Plugin
>  Issue Type: Bug
>Affects Versions: 2.5, 2.6
>Reporter: Hendy Irawan
>Assignee: Robert Scholte
>Priority: Major
>
> e.g.
> {code}
> WEB-INF/classes/logback.xml
> {code}
> in the exploded directory, that/those file(s) is incorrectly still included.
> However in the .war file, that file is properly excluded.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-war-plugin] rfscholte commented on issue #1: [MWAR-371] - Overlays break first-win rule for web resource with target path ending with '/'

[GitBox]

rfscholte commented on issue #1: [MWAR-371] - Overlays break first-win rule for 
web resource with target path ending with '/'
URL: https://github.com/apache/maven-war-plugin/pull/1#issuecomment-552583422
 
 
   PR cannot be merged due to removed code. Can you update the patch?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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] [Closed] (MWAR-314) failOnMissingWebXml ignored when webXml set

[Robert Scholte (Jira)]

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

Robert Scholte closed MWAR-314.
---
Fix Version/s: 3.2.4
 Assignee: Robert Scholte  (was: Karl Heinz Marbaise)
   Resolution: Fixed

Fixed in 
[d98aee4b2c0e58c89f610f4fa1c613861c4cdcd1|https://gitbox.apache.org/repos/asf?p=maven-war-plugin.git;a=commit;h=d98aee4b2c0e58c89f610f4fa1c613861c4cdcd1]
Thanks for the patch!

> failOnMissingWebXml ignored when webXml set
> ---
>
> Key: MWAR-314
> URL: https://issues.apache.org/jira/browse/MWAR-314
> Project: Maven WAR Plugin
>  Issue Type: Bug
>Affects Versions: 2.4
> Environment: Windows 7, IBM RAD 9.0
>Reporter: Jakob Galbavy
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 3.2.4
>
> Attachments: MWAR-314.zip, build.log, pom.xml
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Hi,
> if the webXml attribute is set in the configuration of the plugin (in my case 
> inherited from a parent pom), the failIOnMissingWebXml boolean is ignored.
> To reproduce that:
> * import maven project from attached pom OR create new project (simple 
> archetype), package: war
> * use attached pom.xml OR include the plugin in the pom and set webXml to 
> something and failOnMissingWebXml to false
> * mvn clean install
> -> failed
> 
> * comment the webXml attribute out
> * mvn clean install
> -> success
> cheers
> Jakob
> PS: in my understanding of xml, using  in the pom should set that 
> attribute to NULL, but that doesn't work either. Is that another bug or 
> supposed to be like that?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-war-plugin] rfscholte closed pull request #4: [MWAR-314] Fix for "failOnMissingWebXml ignored when webXml set"

[GitBox]

rfscholte closed pull request #4: [MWAR-314] Fix for "failOnMissingWebXml 
ignored when webXml set"
URL: https://github.com/apache/maven-war-plugin/pull/4
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [maven-war-plugin] rfscholte commented on issue #4: [MWAR-314] Fix for "failOnMissingWebXml ignored when webXml set"

[GitBox]

rfscholte commented on issue #4: [MWAR-314] Fix for "failOnMissingWebXml 
ignored when webXml set"
URL: https://github.com/apache/maven-war-plugin/pull/4#issuecomment-552582919
 
 
   Fixed in 
https://github.com/apache/maven-war-plugin/commit/d98aee4b2c0e58c89f610f4fa1c613861c4cdcd1


This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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] (MWAR-353) Manifest still not written to exploded location

[Robert Scholte (Jira)]

[ 
https://issues.apache.org/jira/browse/MWAR-353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16971816#comment-16971816
 ] 

Robert Scholte commented on MWAR-353:
-

The code currently works like this: first create an exploded war ( as in 
{{war:exploded}} ), use this as input for the war ( as in {{war:war}} ).
The latter is responsible for adding files like MANIFEST.MF, pom.xml and 
pom.properties.
One solution would be to reverse this, so the exploded war looks exactly like 
the warfile, but that needs a huge rewrite, feeding the archiver with the right 
resources.


> Manifest still not written to exploded location
> ---
>
> Key: MWAR-353
> URL: https://issues.apache.org/jira/browse/MWAR-353
> Project: Maven WAR Plugin
>  Issue Type: Bug
>  Components: manifest
>Affects Versions: 2.6
>Reporter: Jakub Bochenski
>Priority: Major
> Fix For: 2.6
>
>
> If I have no manifest files I don't get anything in the exploded location.
> If I put a {{MANIFEST.MF}} under webapp folder's {{META-INF/MANIFEST.MF}} I 
> just get the static file.
> If I set {{archive/manifestFile}} to point at some file I just get the static 
> file.
> Workaround: change
> {code:xml}
>  
>   exploded 
> 
> {code}
> to
> {code:xml}
>  
>   manifest 
>   exploded 
> 
> {code}
>  
> and add the generated files to SCM ignore.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (WAGON-566) Add support for URI normalization

[Michael Osipov (Jira)]

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

Michael Osipov updated WAGON-566:
-
Fix Version/s: waiting-for-feedback

> Add support for URI normalization
> -
>
> Key: WAGON-566
> URL: https://issues.apache.org/jira/browse/WAGON-566
> Project: Maven Wagon
>  Issue Type: Improvement
>  Components: wagon-http
>Affects Versions: 3.3.3
>Reporter: Steve Brown
>Priority: Major
>  Labels: easyfix, newbie
> Fix For: waiting-for-feedback
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> This is a simple fix for MSITE-738. I have set the priority as Major because 
> that is the priority set for MSITE-738
> Some Repository Managers, e.g. JFrog's Artifactory, do not allow puts to a 
> URL with relative path elements ("." or "..").
> Artifactory are addressing the issue for downloads from remote sites 
> ([RTFACT-16457|https://www.jfrog.com/jira/browse/RTFACT-16457]).  Artifactory 
> returns this error:
> {{"status" : 500,"}}
>  {{"Path element cannot end with a dot: sites/ ... redacted ... */../*"}}
> The fix is to amend 
>  {{org.apache.maven.wagon.shared.http.EncodeUtils.encodeURL( String url )}}
>   to normalize the returned URI.
> I will create a pull request.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-5668) post- should always be executed after

[Hudson (Jira)]

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

Hudson commented on MNG-5668:
-

Build failed in Jenkins: Maven TLP » maven » mng-5668-poc #3

See https://builds.apache.org/job/maven-box/job/maven/job/mng-5668-poc/3/

> post- should always be executed after 
> 
>
> Key: MNG-5668
> URL: https://issues.apache.org/jira/browse/MNG-5668
> Project: Maven
>  Issue Type: Sub-task
>  Components: FDPFC, Plugins and Lifecycle
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
>
> Original proposal:
> {quote}
> There are right now 3 phases which also have a pre- and post-, 
> namely integration-test, clean and site. However, even if one has bound goals 
> to the post-phases, they're probably never called.
> When there's an integration-test starting up some server, you'd probably 
> always want to kill it no matter what happens during the IT (let say a NPE).
> The proposal is to execute the post- as the finally block in Java. If 
> you really want to execute only the integration-test without the post, the 
> phase should be marked, e.g. 'mvn [integration-test]', where the brackets 
> lock the phase.
> {quote}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (MWAR-426) Failed to execute goal org.apache.maven.plugins:maven-war-plugin:2.6:exploded (pre-exploded-war) openjdk1.8u222

[Robert Scholte (Jira)]

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

Robert Scholte closed MWAR-426.
---
  Assignee: Robert Scholte
Resolution: Not A Problem

With MWAR-375 the usage of XStream has been removed, which makes this issue 
obsolete.

> Failed to execute goal org.apache.maven.plugins:maven-war-plugin:2.6:exploded 
> (pre-exploded-war) openjdk1.8u222
> ---
>
> Key: MWAR-426
> URL: https://issues.apache.org/jira/browse/MWAR-426
> Project: Maven WAR Plugin
>  Issue Type: Bug
>Affects Versions: 2.6
> Environment: NAME="Ubuntu"
> VERSION="18.04.3 LTS (Bionic Beaver)"
> ID=ubuntu
> ID_LIKE=debian
> PRETTY_NAME="Ubuntu 18.04.3 LTS"
> VERSION_ID="18.04"
> # arch
> x86_64
> # java -version
> openjdk version "1.8.0_222"
> OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1ubuntu1~18.04.1-b10)
> OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode)
> # mvn --version
> Apache Maven 3.6.0
> Maven home: /usr/share/maven
> Java version: 1.8.0_222, vendor: Private Build, runtime: 
> /usr/lib/jvm/java-8-openjdk-amd64/jre
> Default locale: en_US, platform encoding: ANSI_X3.4-1968
> OS name: "linux", version: "4.4.0-154-generic", arch: "amd64", family: "unix"
>Reporter: Vibhuti Sawant
>Assignee: Robert Scholte
>Priority: Blocker
>
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-war-plugin:2.6:exploded (pre-exploded-war) on 
> project alfresco-platform: Execution pre-exploded-war of goal 
> org.apache.maven.plugins:maven-war-plugin:2.6:exploded failed: Cannot 
> construct org.apache.maven.plugin.war.util.WebappStructure as it does not 
> have a no-args constructor : Cannot construct 
> org.apache.maven.plugin.war.util.WebappStructure as it does not have a 
> no-args constructor
> [ERROR]  Debugging information 
> [ERROR] message : Cannot construct 
> org.apache.maven.plugin.war.util.WebappStructure as it does not have a 
> no-args constructor
> [ERROR] cause-exception : 
> com.thoughtworks.xstream.converters.reflection.ObjectAccessException
> [ERROR] cause-message : Cannot construct 
> org.apache.maven.plugin.war.util.WebappStructure as it does not have a 
> no-args constructor
> [ERROR] class : org.apache.maven.plugin.war.util.WebappStructure
> [ERROR] required-type : org.apache.maven.plugin.war.util.WebappStructure
> [ERROR] converter-type : 
> com.thoughtworks.xstream.converters.reflection.ReflectionConverter
> [ERROR] path : /webapp-structure
> [ERROR] version : null
> [ERROR] ---
> [ERROR] -> [Help 1]
>  
> please guide in understanding what could be the issue. As the same command 
> had worked fine with previous openjdk versions.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (MNGSITE-381) Link to Doxia FML full docs is broken

[Dheelus Maximus (Jira)]

Dheelus Maximus created MNGSITE-381:
---

 Summary: Link to Doxia FML full docs is broken
 Key: MNGSITE-381
 URL: https://issues.apache.org/jira/browse/MNGSITE-381
 Project: Maven Project Web Site
  Issue Type: Bug
Reporter: Dheelus Maximus


If I navigate to page 
[http://maven.apache.org/doxia/references/fml-format.html] and then try to 
click on the 
[http://maven.apache.org/doxia/doxia/doxia-modules/doxia-module-fml/xsddoc/index.html]
 link (link on line 'The full documentation is available at here'), it 
indicates that the link is broken.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-war-plugin] rfscholte closed pull request #5: MWAR-422 - Attach artifacts with classifier as primary if requested

[GitBox]

rfscholte closed pull request #5: MWAR-422 - Attach artifacts with classifier 
as primary if requested
URL: https://github.com/apache/maven-war-plugin/pull/5
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [maven-war-plugin] rfscholte commented on issue #5: MWAR-422 - Attach artifacts with classifier as primary if requested

[GitBox]

rfscholte commented on issue #5: MWAR-422 - Attach artifacts with classifier as 
primary if requested
URL: https://github.com/apache/maven-war-plugin/pull/5#issuecomment-552568440
 
 
   Closing as described in https://issues.apache.org/jira/browse/MWAR-422


This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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] [Closed] (MWAR-422) specification of a classifier conflicts with primaryArtifact config

[Robert Scholte (Jira)]

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

Robert Scholte closed MWAR-422.
---
  Assignee: Robert Scholte
Resolution: Won't Fix

In case you don't have a main artifact, the packaging should be pom. However, 
then you'll loose the compiling, testing, etc. (this is something we need to 
fix with a newer modelVersion, I am aware of that).
What you could do now is using {{jar}} as packaging instead to benefit from the 
lifecycle. Next you'll need execution-blocks within the maven-war-plugin, 
specifying the {{war}} goal.
That's the closest you will get within the current limitations of Maven.
So I'll close this one as Wont Fix.

> specification of a classifier conflicts with primaryArtifact config
> ---
>
> Key: MWAR-422
> URL: https://issues.apache.org/jira/browse/MWAR-422
> Project: Maven WAR Plugin
>  Issue Type: Bug
>Reporter: mike duigou
>Assignee: Robert Scholte
>Priority: Major
>  Labels: has-patch
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The documentation for the classifier configuration states "If given, the 
> artifact will be an attachment instead." which ignores the configuration 
> specified by the primaryArtifact config.
> IMO, specification of a classifier should no cause a change in behaviour from 
> attaching main artifact vs attaching supplemental artifact. This behaviour 
> makes it impossible to use the deploy goal with a classifier specified 
> because there is no main artifact.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-dependency-plugin] rfscholte commented on issue #24: [MDEP-435] Added xml outputType to dependency tree

[GitBox]

rfscholte commented on issue #24: [MDEP-435] Added xml outputType to dependency 
tree
URL: 
https://github.com/apache/maven-dependency-plugin/pull/24#issuecomment-552555995
 
 
   Yes, that xml is closer to what I would expect. The roottag could be 
``


This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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] (MNGSITE-380) E-mail adress links on The Team page are invalid

[Gabriel Belingueres (Jira)]

[ 
https://issues.apache.org/jira/browse/MNGSITE-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16971759#comment-16971759
 ] 

Gabriel Belingueres commented on MNGSITE-380:
-

This is fixed in https://issues.apache.org/jira/browse/MPIR-380

However, the vote for version 3.0.1 of the plugin was cancelled. A new call to 
vote is needed in order to release the plugin. Only then the project web site 
can be updated to correct the email links.

> E-mail adress links on The Team page are invalid
> 
>
> Key: MNGSITE-380
> URL: https://issues.apache.org/jira/browse/MNGSITE-380
> Project: Maven Project Web Site
>  Issue Type: Bug
>Reporter: Geert Schuring
>Priority: Major
>  Labels: email, teampage
>
> The email links on page 
> [https://maven.apache.org/team.html|https://maven.apache.org/team.html] are 
> invalid.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ

[Adolfo Cia (Jira)]

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

Adolfo Cia commented on SUREFIRE-1631:
--

[~tibordigana]

Ok, but do you identified now the cause of this issue? the fix that you want me 
to test is still coming today?

> Forked VM terminated without properly saying goodbye with AciveMQ
> -
>
> Key: SUREFIRE-1631
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1631
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20.1, 2.22.0, 3.0.0-M2, 3.0.0-M1
>Reporter: Aaron Digulla
>Assignee: Tibor Digana
>Priority: Major
> Attachments: cmd.PNG, cmd2.PNG, shurefire-shutdownhook-bug-0.0.1.zip
>
>
> I'm seeing spurious "The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?" messages when running unit tests in 
> a big multi-module project.
> OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of 
> Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191.
> I'm running Maven from the command line using MinTTY (Cygwin).
> Things I tried which have no effect:
>  * Reboot / Cold boot (happens first thing on Monday morning when I come into 
> the office and turn on my PC).
>  * More free memory (happens when I only have a single window open). I have 
> 16GB of RAM.
>  * Different terminal. I tried CMD prompt and urxvt (Cygwin/X).
>  * Different versions of the Surefire plugin or Maven
>  * Different JDK 8 builds
> Things that affect the bug:
>  * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log
>  * Redirecting all log output to a file using logback-test.xml
>  * Running Surefire with forkCount=0
>  * Running a subset of the tests (-Dtest=...)
>  * Pending Windows updates (I think, not sure about this one).
> Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never 
> seen it with redirecting log output (~ 10 builds). Redirecting sometimes 
> helps but not always.
> One thing which I notice is that one of the tests creates an ActiveMQ broker 
> and uses a shutdown hook to stop it. So I created a small test project which 
> demonstrates that Surefire will sometimes cut off stdout. I think that 
> happens because the main process kills the child after a timeout (correct?).
> So my guess would be that shutdown hooks can mess with the pipeline between 
> the surefire child VM and main Maven process. ActiveMQ might be worse since 
> it stops threads and execution pools (so the output comes slowly with a 
> couple of exceptions sprinkled in when one component loses connection because 
> another is shutting down).
> But now, it gets weird. When the build succeeds, it takes about ~5 minutes to 
> run 1028 tests. The log is 25 MB.
> When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) 
> and the log stops in the middle of a test but is also 25 MB.
> Some of the time discrepancy is probably because writing to a file is faster 
> than printing on a terminal. The strange part is that the log file is about 
> the same size but 30% of the tests haven't run. Most tests log a lot, do I 
> would expect to see a difference of at least a few MB. The Maven part (which 
> contains escape sequences, etc). is just 60 KB.
> Maybe the parent takes some part of the log output as "child terminated".
> I'm running out of ideas what to try next. I think a way to log the 
> communication between parent and child would help. Also the parent should 
> terminate the child and then read stdout until EOF to we can see anything 
> that happens afterwards.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-wagon] michael-o commented on issue #60: [WAGON-574] advertise jsoup license for shaded jar

[GitBox]

michael-o commented on issue #60: [WAGON-574] advertise jsoup license for 
shaded jar
URL: https://github.com/apache/maven-wagon/pull/60#issuecomment-552510892
 
 
   I just grepped through code and resolver and `filelist` (ci) is not called.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [maven-wagon] michael-o commented on issue #60: [WAGON-574] advertise jsoup license for shaded jar

[GitBox]

michael-o commented on issue #60: [WAGON-574] advertise jsoup license for 
shaded jar
URL: https://github.com/apache/maven-wagon/pull/60#issuecomment-552509259
 
 
   > Just thinking out loud...
   > If @michael-o assumption is correct we could simply not bundle it on 
maven-core at all, if someone hits a ClassNotFoundException he can add the 
jsoup jar to the lib directory.
   
   I really like this idea!
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [maven-wagon] eolivelli commented on issue #60: [WAGON-574] advertise jsoup license for shaded jar

[GitBox]

eolivelli commented on issue #60: [WAGON-574] advertise jsoup license for 
shaded jar
URL: https://github.com/apache/maven-wagon/pull/60#issuecomment-552508101
 
 
   Can't we keep jsoup as simple dependency and hide it somehow in maven core 
with some plexus classloader magic?
   
   Just thinking out loud...
   If @michael-o assumption is correct we could simply not bundle it on 
maven-core at all, if someone hits a ClassNotFoundException he can add the 
jsoup jar to the lib directory.
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ

[Tibor Digana (Jira)]

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

Tibor Digana commented on SUREFIRE-1631:


Important thing is that we know how it behaves and i would simply ignore the 
output of the command in these cases.

> Forked VM terminated without properly saying goodbye with AciveMQ
> -
>
> Key: SUREFIRE-1631
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1631
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20.1, 2.22.0, 3.0.0-M2, 3.0.0-M1
>Reporter: Aaron Digulla
>Assignee: Tibor Digana
>Priority: Major
> Attachments: cmd.PNG, cmd2.PNG, shurefire-shutdownhook-bug-0.0.1.zip
>
>
> I'm seeing spurious "The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?" messages when running unit tests in 
> a big multi-module project.
> OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of 
> Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191.
> I'm running Maven from the command line using MinTTY (Cygwin).
> Things I tried which have no effect:
>  * Reboot / Cold boot (happens first thing on Monday morning when I come into 
> the office and turn on my PC).
>  * More free memory (happens when I only have a single window open). I have 
> 16GB of RAM.
>  * Different terminal. I tried CMD prompt and urxvt (Cygwin/X).
>  * Different versions of the Surefire plugin or Maven
>  * Different JDK 8 builds
> Things that affect the bug:
>  * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log
>  * Redirecting all log output to a file using logback-test.xml
>  * Running Surefire with forkCount=0
>  * Running a subset of the tests (-Dtest=...)
>  * Pending Windows updates (I think, not sure about this one).
> Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never 
> seen it with redirecting log output (~ 10 builds). Redirecting sometimes 
> helps but not always.
> One thing which I notice is that one of the tests creates an ActiveMQ broker 
> and uses a shutdown hook to stop it. So I created a small test project which 
> demonstrates that Surefire will sometimes cut off stdout. I think that 
> happens because the main process kills the child after a timeout (correct?).
> So my guess would be that shutdown hooks can mess with the pipeline between 
> the surefire child VM and main Maven process. ActiveMQ might be worse since 
> it stops threads and execution pools (so the output comes slowly with a 
> couple of exceptions sprinkled in when one component loses connection because 
> another is shutting down).
> But now, it gets weird. When the build succeeds, it takes about ~5 minutes to 
> run 1028 tests. The log is 25 MB.
> When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) 
> and the log stops in the middle of a test but is also 25 MB.
> Some of the time discrepancy is probably because writing to a file is faster 
> than printing on a terminal. The strange part is that the log file is about 
> the same size but 30% of the tests haven't run. Most tests log a lot, do I 
> would expect to see a difference of at least a few MB. The Maven part (which 
> contains escape sequences, etc). is just 60 KB.
> Maybe the parent takes some part of the log output as "child terminated".
> I'm running out of ideas what to try next. I think a way to log the 
> communication between parent and child would help. Also the parent should 
> terminate the child and then read stdout until EOF to we can see anything 
> that happens afterwards.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-wagon] michael-o commented on issue #60: [WAGON-574] advertise jsoup license for shaded jar

[GitBox]

michael-o commented on issue #60: [WAGON-574] advertise jsoup license for 
shaded jar
URL: https://github.com/apache/maven-wagon/pull/60#issuecomment-552499958
 
 
   @hboutemy, I did not test anything. The interface implies that the 
underlying protocol has a notion of directories and collections. HTTP has 
neither. Assuming that some server will deliver some collection is wrong 
because it breaks a basic principle: never do an assumption about an unknown 
environment. Having that said, the given implementation cannot work reliably on 
any type of HTML style listing. Also Wagon is not necessary limited for 
repository manager.
   
   All I am saying is that if a protocol does not define 
collections/directories, don't try to implement them by some crude means with 
some assumptions, simply return `UnimplementedException`. Since HTTP really 
does not, see RFC 7230+, deprecate and mark it for removal.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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] [Updated] (MNGSITE-380) E-mail adress links on The Team page are invalid

[Geert Schuring (Jira)]

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

Geert Schuring updated MNGSITE-380:
---
Labels: email  (was: )

> E-mail adress links on The Team page are invalid
> 
>
> Key: MNGSITE-380
> URL: https://issues.apache.org/jira/browse/MNGSITE-380
> Project: Maven Project Web Site
>  Issue Type: Bug
>Reporter: Geert Schuring
>Priority: Major
>  Labels: email
>
> The email links on page 
> [https://maven.apache.org/team.html|https://maven.apache.org/team.html] are 
> invalid.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MNGSITE-380) E-mail adress links on The Team page are invalid

[Geert Schuring (Jira)]

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

Geert Schuring updated MNGSITE-380:
---
Labels: email teampage  (was: email)

> E-mail adress links on The Team page are invalid
> 
>
> Key: MNGSITE-380
> URL: https://issues.apache.org/jira/browse/MNGSITE-380
> Project: Maven Project Web Site
>  Issue Type: Bug
>Reporter: Geert Schuring
>Priority: Major
>  Labels: email, teampage
>
> The email links on page 
> [https://maven.apache.org/team.html|https://maven.apache.org/team.html] are 
> invalid.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (MNGSITE-380) E-mail adress links on The Team page are invalid

[Geert Schuring (Jira)]

Geert Schuring created MNGSITE-380:
--

 Summary: E-mail adress links on The Team page are invalid
 Key: MNGSITE-380
 URL: https://issues.apache.org/jira/browse/MNGSITE-380
 Project: Maven Project Web Site
  Issue Type: Bug
Reporter: Geert Schuring


The email links on page 
[https://maven.apache.org/team.html|https://maven.apache.org/team.html] are 
invalid.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ

[Adolfo Cia (Jira)]

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

Adolfo Cia edited comment on SUREFIRE-1631 at 11/11/19 3:04 PM:


yeah, you are right, if I put twice
{code:java}
CMD /A /X /C "wmic process where (ProcessId=15672) get CreationDate"{code}

 I get the same output. But I do not see the behavior you described in the 
other comment.


was (Author: adolfo.cia):
yeah, you are right, if I put twice
CMD /A /X /C "wmic process where (ProcessId=15672) get CreationDate"
I get the same output. But I do not see the behavior you described in the other 
comment.

> Forked VM terminated without properly saying goodbye with AciveMQ
> -
>
> Key: SUREFIRE-1631
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1631
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20.1, 2.22.0, 3.0.0-M2, 3.0.0-M1
>Reporter: Aaron Digulla
>Assignee: Tibor Digana
>Priority: Major
> Attachments: cmd.PNG, cmd2.PNG, shurefire-shutdownhook-bug-0.0.1.zip
>
>
> I'm seeing spurious "The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?" messages when running unit tests in 
> a big multi-module project.
> OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of 
> Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191.
> I'm running Maven from the command line using MinTTY (Cygwin).
> Things I tried which have no effect:
>  * Reboot / Cold boot (happens first thing on Monday morning when I come into 
> the office and turn on my PC).
>  * More free memory (happens when I only have a single window open). I have 
> 16GB of RAM.
>  * Different terminal. I tried CMD prompt and urxvt (Cygwin/X).
>  * Different versions of the Surefire plugin or Maven
>  * Different JDK 8 builds
> Things that affect the bug:
>  * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log
>  * Redirecting all log output to a file using logback-test.xml
>  * Running Surefire with forkCount=0
>  * Running a subset of the tests (-Dtest=...)
>  * Pending Windows updates (I think, not sure about this one).
> Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never 
> seen it with redirecting log output (~ 10 builds). Redirecting sometimes 
> helps but not always.
> One thing which I notice is that one of the tests creates an ActiveMQ broker 
> and uses a shutdown hook to stop it. So I created a small test project which 
> demonstrates that Surefire will sometimes cut off stdout. I think that 
> happens because the main process kills the child after a timeout (correct?).
> So my guess would be that shutdown hooks can mess with the pipeline between 
> the surefire child VM and main Maven process. ActiveMQ might be worse since 
> it stops threads and execution pools (so the output comes slowly with a 
> couple of exceptions sprinkled in when one component loses connection because 
> another is shutting down).
> But now, it gets weird. When the build succeeds, it takes about ~5 minutes to 
> run 1028 tests. The log is 25 MB.
> When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) 
> and the log stops in the middle of a test but is also 25 MB.
> Some of the time discrepancy is probably because writing to a file is faster 
> than printing on a terminal. The strange part is that the log file is about 
> the same size but 30% of the tests haven't run. Most tests log a lot, do I 
> would expect to see a difference of at least a few MB. The Maven part (which 
> contains escape sequences, etc). is just 60 KB.
> Maybe the parent takes some part of the log output as "child terminated".
> I'm running out of ideas what to try next. I think a way to log the 
> communication between parent and child would help. Also the parent should 
> terminate the child and then read stdout until EOF to we can see anything 
> that happens afterwards.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ

[Adolfo Cia (Jira)]

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

Adolfo Cia commented on SUREFIRE-1631:
--

yeah, you are right, if I put twice
CMD /A /X /C "wmic process where (ProcessId=15672) get CreationDate"
I get the same output. But I do not see the behavior you described in the other 
comment.

> Forked VM terminated without properly saying goodbye with AciveMQ
> -
>
> Key: SUREFIRE-1631
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1631
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20.1, 2.22.0, 3.0.0-M2, 3.0.0-M1
>Reporter: Aaron Digulla
>Assignee: Tibor Digana
>Priority: Major
> Attachments: cmd.PNG, cmd2.PNG, shurefire-shutdownhook-bug-0.0.1.zip
>
>
> I'm seeing spurious "The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?" messages when running unit tests in 
> a big multi-module project.
> OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of 
> Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191.
> I'm running Maven from the command line using MinTTY (Cygwin).
> Things I tried which have no effect:
>  * Reboot / Cold boot (happens first thing on Monday morning when I come into 
> the office and turn on my PC).
>  * More free memory (happens when I only have a single window open). I have 
> 16GB of RAM.
>  * Different terminal. I tried CMD prompt and urxvt (Cygwin/X).
>  * Different versions of the Surefire plugin or Maven
>  * Different JDK 8 builds
> Things that affect the bug:
>  * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log
>  * Redirecting all log output to a file using logback-test.xml
>  * Running Surefire with forkCount=0
>  * Running a subset of the tests (-Dtest=...)
>  * Pending Windows updates (I think, not sure about this one).
> Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never 
> seen it with redirecting log output (~ 10 builds). Redirecting sometimes 
> helps but not always.
> One thing which I notice is that one of the tests creates an ActiveMQ broker 
> and uses a shutdown hook to stop it. So I created a small test project which 
> demonstrates that Surefire will sometimes cut off stdout. I think that 
> happens because the main process kills the child after a timeout (correct?).
> So my guess would be that shutdown hooks can mess with the pipeline between 
> the surefire child VM and main Maven process. ActiveMQ might be worse since 
> it stops threads and execution pools (so the output comes slowly with a 
> couple of exceptions sprinkled in when one component loses connection because 
> another is shutting down).
> But now, it gets weird. When the build succeeds, it takes about ~5 minutes to 
> run 1028 tests. The log is 25 MB.
> When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) 
> and the log stops in the middle of a test but is also 25 MB.
> Some of the time discrepancy is probably because writing to a file is faster 
> than printing on a terminal. The strange part is that the log file is about 
> the same size but 30% of the tests haven't run. Most tests log a lot, do I 
> would expect to see a difference of at least a few MB. The Maven part (which 
> contains escape sequences, etc). is just 60 KB.
> Maybe the parent takes some part of the log output as "child terminated".
> I'm running out of ideas what to try next. I think a way to log the 
> communication between parent and child would help. Also the parent should 
> terminate the child and then read stdout until EOF to we can see anything 
> that happens afterwards.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ

[Tibor Digana (Jira)]

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

Tibor Digana commented on SUREFIRE-1631:


I have the same experiences. You can freely call the first command twice and 
you should also have the same output.
I was looking for some bug with buffer size but it  was not confirmed.

> Forked VM terminated without properly saying goodbye with AciveMQ
> -
>
> Key: SUREFIRE-1631
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1631
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20.1, 2.22.0, 3.0.0-M2, 3.0.0-M1
>Reporter: Aaron Digulla
>Assignee: Tibor Digana
>Priority: Major
> Attachments: cmd.PNG, cmd2.PNG, shurefire-shutdownhook-bug-0.0.1.zip
>
>
> I'm seeing spurious "The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?" messages when running unit tests in 
> a big multi-module project.
> OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of 
> Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191.
> I'm running Maven from the command line using MinTTY (Cygwin).
> Things I tried which have no effect:
>  * Reboot / Cold boot (happens first thing on Monday morning when I come into 
> the office and turn on my PC).
>  * More free memory (happens when I only have a single window open). I have 
> 16GB of RAM.
>  * Different terminal. I tried CMD prompt and urxvt (Cygwin/X).
>  * Different versions of the Surefire plugin or Maven
>  * Different JDK 8 builds
> Things that affect the bug:
>  * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log
>  * Redirecting all log output to a file using logback-test.xml
>  * Running Surefire with forkCount=0
>  * Running a subset of the tests (-Dtest=...)
>  * Pending Windows updates (I think, not sure about this one).
> Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never 
> seen it with redirecting log output (~ 10 builds). Redirecting sometimes 
> helps but not always.
> One thing which I notice is that one of the tests creates an ActiveMQ broker 
> and uses a shutdown hook to stop it. So I created a small test project which 
> demonstrates that Surefire will sometimes cut off stdout. I think that 
> happens because the main process kills the child after a timeout (correct?).
> So my guess would be that shutdown hooks can mess with the pipeline between 
> the surefire child VM and main Maven process. ActiveMQ might be worse since 
> it stops threads and execution pools (so the output comes slowly with a 
> couple of exceptions sprinkled in when one component loses connection because 
> another is shutting down).
> But now, it gets weird. When the build succeeds, it takes about ~5 minutes to 
> run 1028 tests. The log is 25 MB.
> When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) 
> and the log stops in the middle of a test but is also 25 MB.
> Some of the time discrepancy is probably because writing to a file is faster 
> than printing on a terminal. The strange part is that the log file is about 
> the same size but 30% of the tests haven't run. Most tests log a lot, do I 
> would expect to see a difference of at least a few MB. The Maven part (which 
> contains escape sequences, etc). is just 60 KB.
> Maybe the parent takes some part of the log output as "child terminated".
> I'm running out of ideas what to try next. I think a way to log the 
> communication between parent and child would help. Also the parent should 
> terminate the child and then read stdout until EOF to we can see anything 
> that happens afterwards.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ

[Adolfo Cia (Jira)]

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

Adolfo Cia edited comment on SUREFIRE-1631 at 11/11/19 2:49 PM:


It is a two step process, first you put
{code:java}
CMD /A /X /C "wmic process where (ProcessId=15672) get CreationDate"{code}
, then starts cmd, and then you put
{code:java}
wmic process where (ProcessId=15672) get CreationDate{code}


was (Author: adolfo.cia):
It is a two step process, first you put CMD /A /X /C "wmic process where 
(ProcessId=15672) get CreationDate", then starts cmd, and then you put wmic 
process where (ProcessId=15672) get CreationDate

> Forked VM terminated without properly saying goodbye with AciveMQ
> -
>
> Key: SUREFIRE-1631
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1631
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20.1, 2.22.0, 3.0.0-M2, 3.0.0-M1
>Reporter: Aaron Digulla
>Assignee: Tibor Digana
>Priority: Major
> Attachments: cmd.PNG, cmd2.PNG, shurefire-shutdownhook-bug-0.0.1.zip
>
>
> I'm seeing spurious "The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?" messages when running unit tests in 
> a big multi-module project.
> OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of 
> Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191.
> I'm running Maven from the command line using MinTTY (Cygwin).
> Things I tried which have no effect:
>  * Reboot / Cold boot (happens first thing on Monday morning when I come into 
> the office and turn on my PC).
>  * More free memory (happens when I only have a single window open). I have 
> 16GB of RAM.
>  * Different terminal. I tried CMD prompt and urxvt (Cygwin/X).
>  * Different versions of the Surefire plugin or Maven
>  * Different JDK 8 builds
> Things that affect the bug:
>  * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log
>  * Redirecting all log output to a file using logback-test.xml
>  * Running Surefire with forkCount=0
>  * Running a subset of the tests (-Dtest=...)
>  * Pending Windows updates (I think, not sure about this one).
> Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never 
> seen it with redirecting log output (~ 10 builds). Redirecting sometimes 
> helps but not always.
> One thing which I notice is that one of the tests creates an ActiveMQ broker 
> and uses a shutdown hook to stop it. So I created a small test project which 
> demonstrates that Surefire will sometimes cut off stdout. I think that 
> happens because the main process kills the child after a timeout (correct?).
> So my guess would be that shutdown hooks can mess with the pipeline between 
> the surefire child VM and main Maven process. ActiveMQ might be worse since 
> it stops threads and execution pools (so the output comes slowly with a 
> couple of exceptions sprinkled in when one component loses connection because 
> another is shutting down).
> But now, it gets weird. When the build succeeds, it takes about ~5 minutes to 
> run 1028 tests. The log is 25 MB.
> When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) 
> and the log stops in the middle of a test but is also 25 MB.
> Some of the time discrepancy is probably because writing to a file is faster 
> than printing on a terminal. The strange part is that the log file is about 
> the same size but 30% of the tests haven't run. Most tests log a lot, do I 
> would expect to see a difference of at least a few MB. The Maven part (which 
> contains escape sequences, etc). is just 60 KB.
> Maybe the parent takes some part of the log output as "child terminated".
> I'm running out of ideas what to try next. I think a way to log the 
> communication between parent and child would help. Also the parent should 
> terminate the child and then read stdout until EOF to we can see anything 
> that happens afterwards.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ

[Adolfo Cia (Jira)]

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

Adolfo Cia commented on SUREFIRE-1631:
--

It is a two step process, first you put CMD /A /X /C "wmic process where 
(ProcessId=15672) get CreationDate", then starts cmd, and then you put wmic 
process where (ProcessId=15672) get CreationDate

> Forked VM terminated without properly saying goodbye with AciveMQ
> -
>
> Key: SUREFIRE-1631
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1631
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20.1, 2.22.0, 3.0.0-M2, 3.0.0-M1
>Reporter: Aaron Digulla
>Assignee: Tibor Digana
>Priority: Major
> Attachments: cmd.PNG, cmd2.PNG, shurefire-shutdownhook-bug-0.0.1.zip
>
>
> I'm seeing spurious "The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?" messages when running unit tests in 
> a big multi-module project.
> OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of 
> Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191.
> I'm running Maven from the command line using MinTTY (Cygwin).
> Things I tried which have no effect:
>  * Reboot / Cold boot (happens first thing on Monday morning when I come into 
> the office and turn on my PC).
>  * More free memory (happens when I only have a single window open). I have 
> 16GB of RAM.
>  * Different terminal. I tried CMD prompt and urxvt (Cygwin/X).
>  * Different versions of the Surefire plugin or Maven
>  * Different JDK 8 builds
> Things that affect the bug:
>  * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log
>  * Redirecting all log output to a file using logback-test.xml
>  * Running Surefire with forkCount=0
>  * Running a subset of the tests (-Dtest=...)
>  * Pending Windows updates (I think, not sure about this one).
> Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never 
> seen it with redirecting log output (~ 10 builds). Redirecting sometimes 
> helps but not always.
> One thing which I notice is that one of the tests creates an ActiveMQ broker 
> and uses a shutdown hook to stop it. So I created a small test project which 
> demonstrates that Surefire will sometimes cut off stdout. I think that 
> happens because the main process kills the child after a timeout (correct?).
> So my guess would be that shutdown hooks can mess with the pipeline between 
> the surefire child VM and main Maven process. ActiveMQ might be worse since 
> it stops threads and execution pools (so the output comes slowly with a 
> couple of exceptions sprinkled in when one component loses connection because 
> another is shutting down).
> But now, it gets weird. When the build succeeds, it takes about ~5 minutes to 
> run 1028 tests. The log is 25 MB.
> When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) 
> and the log stops in the middle of a test but is also 25 MB.
> Some of the time discrepancy is probably because writing to a file is faster 
> than printing on a terminal. The strange part is that the log file is about 
> the same size but 30% of the tests haven't run. Most tests log a lot, do I 
> would expect to see a difference of at least a few MB. The Maven part (which 
> contains escape sequences, etc). is just 60 KB.
> Maybe the parent takes some part of the log output as "child terminated".
> I'm running out of ideas what to try next. I think a way to log the 
> communication between parent and child would help. Also the parent should 
> terminate the child and then read stdout until EOF to we can see anything 
> that happens afterwards.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ

[Adolfo Cia (Jira)]

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

Adolfo Cia updated SUREFIRE-1631:
-
Attachment: cmd2.PNG

> Forked VM terminated without properly saying goodbye with AciveMQ
> -
>
> Key: SUREFIRE-1631
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1631
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20.1, 2.22.0, 3.0.0-M2, 3.0.0-M1
>Reporter: Aaron Digulla
>Assignee: Tibor Digana
>Priority: Major
> Attachments: cmd.PNG, cmd2.PNG, shurefire-shutdownhook-bug-0.0.1.zip
>
>
> I'm seeing spurious "The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?" messages when running unit tests in 
> a big multi-module project.
> OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of 
> Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191.
> I'm running Maven from the command line using MinTTY (Cygwin).
> Things I tried which have no effect:
>  * Reboot / Cold boot (happens first thing on Monday morning when I come into 
> the office and turn on my PC).
>  * More free memory (happens when I only have a single window open). I have 
> 16GB of RAM.
>  * Different terminal. I tried CMD prompt and urxvt (Cygwin/X).
>  * Different versions of the Surefire plugin or Maven
>  * Different JDK 8 builds
> Things that affect the bug:
>  * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log
>  * Redirecting all log output to a file using logback-test.xml
>  * Running Surefire with forkCount=0
>  * Running a subset of the tests (-Dtest=...)
>  * Pending Windows updates (I think, not sure about this one).
> Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never 
> seen it with redirecting log output (~ 10 builds). Redirecting sometimes 
> helps but not always.
> One thing which I notice is that one of the tests creates an ActiveMQ broker 
> and uses a shutdown hook to stop it. So I created a small test project which 
> demonstrates that Surefire will sometimes cut off stdout. I think that 
> happens because the main process kills the child after a timeout (correct?).
> So my guess would be that shutdown hooks can mess with the pipeline between 
> the surefire child VM and main Maven process. ActiveMQ might be worse since 
> it stops threads and execution pools (so the output comes slowly with a 
> couple of exceptions sprinkled in when one component loses connection because 
> another is shutting down).
> But now, it gets weird. When the build succeeds, it takes about ~5 minutes to 
> run 1028 tests. The log is 25 MB.
> When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) 
> and the log stops in the middle of a test but is also 25 MB.
> Some of the time discrepancy is probably because writing to a file is faster 
> than printing on a terminal. The strange part is that the log file is about 
> the same size but 30% of the tests haven't run. Most tests log a lot, do I 
> would expect to see a difference of at least a few MB. The Maven part (which 
> contains escape sequences, etc). is just 60 KB.
> Maybe the parent takes some part of the log output as "child terminated".
> I'm running out of ideas what to try next. I think a way to log the 
> communication between parent and child would help. Also the parent should 
> terminate the child and then read stdout until EOF to we can see anything 
> that happens afterwards.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ

[Adolfo Cia (Jira)]

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

Adolfo Cia commented on SUREFIRE-1631:
--

on GitBash I do not see that problem.

this is on a fresh console:

!cmd2.PNG!

> Forked VM terminated without properly saying goodbye with AciveMQ
> -
>
> Key: SUREFIRE-1631
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1631
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20.1, 2.22.0, 3.0.0-M2, 3.0.0-M1
>Reporter: Aaron Digulla
>Assignee: Tibor Digana
>Priority: Major
> Attachments: cmd.PNG, cmd2.PNG, shurefire-shutdownhook-bug-0.0.1.zip
>
>
> I'm seeing spurious "The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?" messages when running unit tests in 
> a big multi-module project.
> OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of 
> Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191.
> I'm running Maven from the command line using MinTTY (Cygwin).
> Things I tried which have no effect:
>  * Reboot / Cold boot (happens first thing on Monday morning when I come into 
> the office and turn on my PC).
>  * More free memory (happens when I only have a single window open). I have 
> 16GB of RAM.
>  * Different terminal. I tried CMD prompt and urxvt (Cygwin/X).
>  * Different versions of the Surefire plugin or Maven
>  * Different JDK 8 builds
> Things that affect the bug:
>  * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log
>  * Redirecting all log output to a file using logback-test.xml
>  * Running Surefire with forkCount=0
>  * Running a subset of the tests (-Dtest=...)
>  * Pending Windows updates (I think, not sure about this one).
> Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never 
> seen it with redirecting log output (~ 10 builds). Redirecting sometimes 
> helps but not always.
> One thing which I notice is that one of the tests creates an ActiveMQ broker 
> and uses a shutdown hook to stop it. So I created a small test project which 
> demonstrates that Surefire will sometimes cut off stdout. I think that 
> happens because the main process kills the child after a timeout (correct?).
> So my guess would be that shutdown hooks can mess with the pipeline between 
> the surefire child VM and main Maven process. ActiveMQ might be worse since 
> it stops threads and execution pools (so the output comes slowly with a 
> couple of exceptions sprinkled in when one component loses connection because 
> another is shutting down).
> But now, it gets weird. When the build succeeds, it takes about ~5 minutes to 
> run 1028 tests. The log is 25 MB.
> When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) 
> and the log stops in the middle of a test but is also 25 MB.
> Some of the time discrepancy is probably because writing to a file is faster 
> than printing on a terminal. The strange part is that the log file is about 
> the same size but 30% of the tests haven't run. Most tests log a lot, do I 
> would expect to see a difference of at least a few MB. The Maven part (which 
> contains escape sequences, etc). is just 60 KB.
> Maybe the parent takes some part of the log output as "child terminated".
> I'm running out of ideas what to try next. I think a way to log the 
> communication between parent and child would help. Also the parent should 
> terminate the child and then read stdout until EOF to we can see anything 
> that happens afterwards.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ

[Tibor Digana (Jira)]

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

Tibor Digana commented on SUREFIRE-1631:


the comment 
https://issues.apache.org/jira/browse/SUREFIRE-1631?focusedCommentId=16971571=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16971571
 was refferring to GitBash

> Forked VM terminated without properly saying goodbye with AciveMQ
> -
>
> Key: SUREFIRE-1631
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1631
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20.1, 2.22.0, 3.0.0-M2, 3.0.0-M1
>Reporter: Aaron Digulla
>Assignee: Tibor Digana
>Priority: Major
> Attachments: cmd.PNG, shurefire-shutdownhook-bug-0.0.1.zip
>
>
> I'm seeing spurious "The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?" messages when running unit tests in 
> a big multi-module project.
> OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of 
> Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191.
> I'm running Maven from the command line using MinTTY (Cygwin).
> Things I tried which have no effect:
>  * Reboot / Cold boot (happens first thing on Monday morning when I come into 
> the office and turn on my PC).
>  * More free memory (happens when I only have a single window open). I have 
> 16GB of RAM.
>  * Different terminal. I tried CMD prompt and urxvt (Cygwin/X).
>  * Different versions of the Surefire plugin or Maven
>  * Different JDK 8 builds
> Things that affect the bug:
>  * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log
>  * Redirecting all log output to a file using logback-test.xml
>  * Running Surefire with forkCount=0
>  * Running a subset of the tests (-Dtest=...)
>  * Pending Windows updates (I think, not sure about this one).
> Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never 
> seen it with redirecting log output (~ 10 builds). Redirecting sometimes 
> helps but not always.
> One thing which I notice is that one of the tests creates an ActiveMQ broker 
> and uses a shutdown hook to stop it. So I created a small test project which 
> demonstrates that Surefire will sometimes cut off stdout. I think that 
> happens because the main process kills the child after a timeout (correct?).
> So my guess would be that shutdown hooks can mess with the pipeline between 
> the surefire child VM and main Maven process. ActiveMQ might be worse since 
> it stops threads and execution pools (so the output comes slowly with a 
> couple of exceptions sprinkled in when one component loses connection because 
> another is shutting down).
> But now, it gets weird. When the build succeeds, it takes about ~5 minutes to 
> run 1028 tests. The log is 25 MB.
> When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) 
> and the log stops in the middle of a test but is also 25 MB.
> Some of the time discrepancy is probably because writing to a file is faster 
> than printing on a terminal. The strange part is that the log file is about 
> the same size but 30% of the tests haven't run. Most tests log a lot, do I 
> would expect to see a difference of at least a few MB. The Maven part (which 
> contains escape sequences, etc). is just 60 KB.
> Maybe the parent takes some part of the log output as "child terminated".
> I'm running out of ideas what to try next. I think a way to log the 
> communication between parent and child would help. Also the parent should 
> terminate the child and then read stdout until EOF to we can see anything 
> that happens afterwards.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ

[Tibor Digana (Jira)]

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

Tibor Digana commented on SUREFIRE-1631:


on both: cmd.exe (successful) and Git Bash console (bad)

> Forked VM terminated without properly saying goodbye with AciveMQ
> -
>
> Key: SUREFIRE-1631
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1631
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20.1, 2.22.0, 3.0.0-M2, 3.0.0-M1
>Reporter: Aaron Digulla
>Assignee: Tibor Digana
>Priority: Major
> Attachments: cmd.PNG, shurefire-shutdownhook-bug-0.0.1.zip
>
>
> I'm seeing spurious "The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?" messages when running unit tests in 
> a big multi-module project.
> OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of 
> Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191.
> I'm running Maven from the command line using MinTTY (Cygwin).
> Things I tried which have no effect:
>  * Reboot / Cold boot (happens first thing on Monday morning when I come into 
> the office and turn on my PC).
>  * More free memory (happens when I only have a single window open). I have 
> 16GB of RAM.
>  * Different terminal. I tried CMD prompt and urxvt (Cygwin/X).
>  * Different versions of the Surefire plugin or Maven
>  * Different JDK 8 builds
> Things that affect the bug:
>  * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log
>  * Redirecting all log output to a file using logback-test.xml
>  * Running Surefire with forkCount=0
>  * Running a subset of the tests (-Dtest=...)
>  * Pending Windows updates (I think, not sure about this one).
> Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never 
> seen it with redirecting log output (~ 10 builds). Redirecting sometimes 
> helps but not always.
> One thing which I notice is that one of the tests creates an ActiveMQ broker 
> and uses a shutdown hook to stop it. So I created a small test project which 
> demonstrates that Surefire will sometimes cut off stdout. I think that 
> happens because the main process kills the child after a timeout (correct?).
> So my guess would be that shutdown hooks can mess with the pipeline between 
> the surefire child VM and main Maven process. ActiveMQ might be worse since 
> it stops threads and execution pools (so the output comes slowly with a 
> couple of exceptions sprinkled in when one component loses connection because 
> another is shutting down).
> But now, it gets weird. When the build succeeds, it takes about ~5 minutes to 
> run 1028 tests. The log is 25 MB.
> When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) 
> and the log stops in the middle of a test but is also 25 MB.
> Some of the time discrepancy is probably because writing to a file is faster 
> than printing on a terminal. The strange part is that the log file is about 
> the same size but 30% of the tests haven't run. Most tests log a lot, do I 
> would expect to see a difference of at least a few MB. The Maven part (which 
> contains escape sequences, etc). is just 60 KB.
> Maybe the parent takes some part of the log output as "child terminated".
> I'm running out of ideas what to try next. I think a way to log the 
> communication between parent and child would help. Also the parent should 
> terminate the child and then read stdout until EOF to we can see anything 
> that happens afterwards.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ

[Adolfo Cia (Jira)]

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

Adolfo Cia commented on SUREFIRE-1631:
--

on which console do you test that? on cmd.exe (command prompt) that does not 
happen to me

> Forked VM terminated without properly saying goodbye with AciveMQ
> -
>
> Key: SUREFIRE-1631
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1631
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20.1, 2.22.0, 3.0.0-M2, 3.0.0-M1
>Reporter: Aaron Digulla
>Assignee: Tibor Digana
>Priority: Major
> Attachments: cmd.PNG, shurefire-shutdownhook-bug-0.0.1.zip
>
>
> I'm seeing spurious "The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?" messages when running unit tests in 
> a big multi-module project.
> OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of 
> Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191.
> I'm running Maven from the command line using MinTTY (Cygwin).
> Things I tried which have no effect:
>  * Reboot / Cold boot (happens first thing on Monday morning when I come into 
> the office and turn on my PC).
>  * More free memory (happens when I only have a single window open). I have 
> 16GB of RAM.
>  * Different terminal. I tried CMD prompt and urxvt (Cygwin/X).
>  * Different versions of the Surefire plugin or Maven
>  * Different JDK 8 builds
> Things that affect the bug:
>  * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log
>  * Redirecting all log output to a file using logback-test.xml
>  * Running Surefire with forkCount=0
>  * Running a subset of the tests (-Dtest=...)
>  * Pending Windows updates (I think, not sure about this one).
> Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never 
> seen it with redirecting log output (~ 10 builds). Redirecting sometimes 
> helps but not always.
> One thing which I notice is that one of the tests creates an ActiveMQ broker 
> and uses a shutdown hook to stop it. So I created a small test project which 
> demonstrates that Surefire will sometimes cut off stdout. I think that 
> happens because the main process kills the child after a timeout (correct?).
> So my guess would be that shutdown hooks can mess with the pipeline between 
> the surefire child VM and main Maven process. ActiveMQ might be worse since 
> it stops threads and execution pools (so the output comes slowly with a 
> couple of exceptions sprinkled in when one component loses connection because 
> another is shutting down).
> But now, it gets weird. When the build succeeds, it takes about ~5 minutes to 
> run 1028 tests. The log is 25 MB.
> When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) 
> and the log stops in the middle of a test but is also 25 MB.
> Some of the time discrepancy is probably because writing to a file is faster 
> than printing on a terminal. The strange part is that the log file is about 
> the same size but 30% of the tests haven't run. Most tests log a lot, do I 
> would expect to see a difference of at least a few MB. The Maven part (which 
> contains escape sequences, etc). is just 60 KB.
> Maybe the parent takes some part of the log output as "child terminated".
> I'm running out of ideas what to try next. I think a way to log the 
> communication between parent and child would help. Also the parent should 
> terminate the child and then read stdout until EOF to we can see anything 
> that happens afterwards.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ

[Tibor Digana (Jira)]

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

Tibor Digana commented on SUREFIRE-1631:


[~adolfo.cia]
If I run the command the first time on fresh console, it does not report the 
CreationDate.
If i run it the second time, it reports on the console.
Do you have the same experiences?

> Forked VM terminated without properly saying goodbye with AciveMQ
> -
>
> Key: SUREFIRE-1631
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1631
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20.1, 2.22.0, 3.0.0-M2, 3.0.0-M1
>Reporter: Aaron Digulla
>Assignee: Tibor Digana
>Priority: Major
> Attachments: cmd.PNG, shurefire-shutdownhook-bug-0.0.1.zip
>
>
> I'm seeing spurious "The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?" messages when running unit tests in 
> a big multi-module project.
> OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of 
> Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191.
> I'm running Maven from the command line using MinTTY (Cygwin).
> Things I tried which have no effect:
>  * Reboot / Cold boot (happens first thing on Monday morning when I come into 
> the office and turn on my PC).
>  * More free memory (happens when I only have a single window open). I have 
> 16GB of RAM.
>  * Different terminal. I tried CMD prompt and urxvt (Cygwin/X).
>  * Different versions of the Surefire plugin or Maven
>  * Different JDK 8 builds
> Things that affect the bug:
>  * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log
>  * Redirecting all log output to a file using logback-test.xml
>  * Running Surefire with forkCount=0
>  * Running a subset of the tests (-Dtest=...)
>  * Pending Windows updates (I think, not sure about this one).
> Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never 
> seen it with redirecting log output (~ 10 builds). Redirecting sometimes 
> helps but not always.
> One thing which I notice is that one of the tests creates an ActiveMQ broker 
> and uses a shutdown hook to stop it. So I created a small test project which 
> demonstrates that Surefire will sometimes cut off stdout. I think that 
> happens because the main process kills the child after a timeout (correct?).
> So my guess would be that shutdown hooks can mess with the pipeline between 
> the surefire child VM and main Maven process. ActiveMQ might be worse since 
> it stops threads and execution pools (so the output comes slowly with a 
> couple of exceptions sprinkled in when one component loses connection because 
> another is shutting down).
> But now, it gets weird. When the build succeeds, it takes about ~5 minutes to 
> run 1028 tests. The log is 25 MB.
> When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) 
> and the log stops in the middle of a test but is also 25 MB.
> Some of the time discrepancy is probably because writing to a file is faster 
> than printing on a terminal. The strange part is that the log file is about 
> the same size but 30% of the tests haven't run. Most tests log a lot, do I 
> would expect to see a difference of at least a few MB. The Maven part (which 
> contains escape sequences, etc). is just 60 KB.
> Maybe the parent takes some part of the log output as "child terminated".
> I'm running out of ideas what to try next. I think a way to log the 
> communication between parent and child would help. Also the parent should 
> terminate the child and then read stdout until EOF to we can see anything 
> that happens afterwards.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ

[Adolfo Cia (Jira)]

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

Adolfo Cia edited comment on SUREFIRE-1631 at 11/11/19 1:56 PM:


[~tibordigana]

so the problem is within the consoles that runs the mvn commands/goals?

Yes, I'm at work for the next 8 hours, tag me whenever you want me to test the 
fix.


was (Author: adolfo.cia):
[~tibordigana]

so the problem is within the consoles that runs the mvn commands/goals?

Yes, I'm at work for the next 8 hours, tag me wherever you want me to test the 
fix.

> Forked VM terminated without properly saying goodbye with AciveMQ
> -
>
> Key: SUREFIRE-1631
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1631
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20.1, 2.22.0, 3.0.0-M2, 3.0.0-M1
>Reporter: Aaron Digulla
>Assignee: Tibor Digana
>Priority: Major
> Attachments: cmd.PNG, shurefire-shutdownhook-bug-0.0.1.zip
>
>
> I'm seeing spurious "The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?" messages when running unit tests in 
> a big multi-module project.
> OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of 
> Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191.
> I'm running Maven from the command line using MinTTY (Cygwin).
> Things I tried which have no effect:
>  * Reboot / Cold boot (happens first thing on Monday morning when I come into 
> the office and turn on my PC).
>  * More free memory (happens when I only have a single window open). I have 
> 16GB of RAM.
>  * Different terminal. I tried CMD prompt and urxvt (Cygwin/X).
>  * Different versions of the Surefire plugin or Maven
>  * Different JDK 8 builds
> Things that affect the bug:
>  * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log
>  * Redirecting all log output to a file using logback-test.xml
>  * Running Surefire with forkCount=0
>  * Running a subset of the tests (-Dtest=...)
>  * Pending Windows updates (I think, not sure about this one).
> Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never 
> seen it with redirecting log output (~ 10 builds). Redirecting sometimes 
> helps but not always.
> One thing which I notice is that one of the tests creates an ActiveMQ broker 
> and uses a shutdown hook to stop it. So I created a small test project which 
> demonstrates that Surefire will sometimes cut off stdout. I think that 
> happens because the main process kills the child after a timeout (correct?).
> So my guess would be that shutdown hooks can mess with the pipeline between 
> the surefire child VM and main Maven process. ActiveMQ might be worse since 
> it stops threads and execution pools (so the output comes slowly with a 
> couple of exceptions sprinkled in when one component loses connection because 
> another is shutting down).
> But now, it gets weird. When the build succeeds, it takes about ~5 minutes to 
> run 1028 tests. The log is 25 MB.
> When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) 
> and the log stops in the middle of a test but is also 25 MB.
> Some of the time discrepancy is probably because writing to a file is faster 
> than printing on a terminal. The strange part is that the log file is about 
> the same size but 30% of the tests haven't run. Most tests log a lot, do I 
> would expect to see a difference of at least a few MB. The Maven part (which 
> contains escape sequences, etc). is just 60 KB.
> Maybe the parent takes some part of the log output as "child terminated".
> I'm running out of ideas what to try next. I think a way to log the 
> communication between parent and child would help. Also the parent should 
> terminate the child and then read stdout until EOF to we can see anything 
> that happens afterwards.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ

[Adolfo Cia (Jira)]

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

Adolfo Cia commented on SUREFIRE-1631:
--

[~tibordigana]

so the problem is within the consoles that runs the mvn commands/goals?

Yes, I'm at work for the next 8 hours, tag me wherever you want me to test the 
fix.

> Forked VM terminated without properly saying goodbye with AciveMQ
> -
>
> Key: SUREFIRE-1631
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1631
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20.1, 2.22.0, 3.0.0-M2, 3.0.0-M1
>Reporter: Aaron Digulla
>Assignee: Tibor Digana
>Priority: Major
> Attachments: cmd.PNG, shurefire-shutdownhook-bug-0.0.1.zip
>
>
> I'm seeing spurious "The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?" messages when running unit tests in 
> a big multi-module project.
> OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of 
> Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191.
> I'm running Maven from the command line using MinTTY (Cygwin).
> Things I tried which have no effect:
>  * Reboot / Cold boot (happens first thing on Monday morning when I come into 
> the office and turn on my PC).
>  * More free memory (happens when I only have a single window open). I have 
> 16GB of RAM.
>  * Different terminal. I tried CMD prompt and urxvt (Cygwin/X).
>  * Different versions of the Surefire plugin or Maven
>  * Different JDK 8 builds
> Things that affect the bug:
>  * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log
>  * Redirecting all log output to a file using logback-test.xml
>  * Running Surefire with forkCount=0
>  * Running a subset of the tests (-Dtest=...)
>  * Pending Windows updates (I think, not sure about this one).
> Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never 
> seen it with redirecting log output (~ 10 builds). Redirecting sometimes 
> helps but not always.
> One thing which I notice is that one of the tests creates an ActiveMQ broker 
> and uses a shutdown hook to stop it. So I created a small test project which 
> demonstrates that Surefire will sometimes cut off stdout. I think that 
> happens because the main process kills the child after a timeout (correct?).
> So my guess would be that shutdown hooks can mess with the pipeline between 
> the surefire child VM and main Maven process. ActiveMQ might be worse since 
> it stops threads and execution pools (so the output comes slowly with a 
> couple of exceptions sprinkled in when one component loses connection because 
> another is shutting down).
> But now, it gets weird. When the build succeeds, it takes about ~5 minutes to 
> run 1028 tests. The log is 25 MB.
> When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) 
> and the log stops in the middle of a test but is also 25 MB.
> Some of the time discrepancy is probably because writing to a file is faster 
> than printing on a terminal. The strange part is that the log file is about 
> the same size but 30% of the tests haven't run. Most tests log a lot, do I 
> would expect to see a difference of at least a few MB. The Maven part (which 
> contains escape sequences, etc). is just 60 KB.
> Maybe the parent takes some part of the log output as "child terminated".
> I'm running out of ideas what to try next. I think a way to log the 
> communication between parent and child would help. Also the parent should 
> terminate the child and then read stdout until EOF to we can see anything 
> that happens afterwards.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ

[Tibor Digana (Jira)]

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

Tibor Digana commented on SUREFIRE-1631:


ok, it seems that it is the same root cause and the fix would be relevant for 
all consoles.
Would you be available to run the fix in next 5 hours?

> Forked VM terminated without properly saying goodbye with AciveMQ
> -
>
> Key: SUREFIRE-1631
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1631
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20.1, 2.22.0, 3.0.0-M2, 3.0.0-M1
>Reporter: Aaron Digulla
>Assignee: Tibor Digana
>Priority: Major
> Attachments: cmd.PNG, shurefire-shutdownhook-bug-0.0.1.zip
>
>
> I'm seeing spurious "The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?" messages when running unit tests in 
> a big multi-module project.
> OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of 
> Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191.
> I'm running Maven from the command line using MinTTY (Cygwin).
> Things I tried which have no effect:
>  * Reboot / Cold boot (happens first thing on Monday morning when I come into 
> the office and turn on my PC).
>  * More free memory (happens when I only have a single window open). I have 
> 16GB of RAM.
>  * Different terminal. I tried CMD prompt and urxvt (Cygwin/X).
>  * Different versions of the Surefire plugin or Maven
>  * Different JDK 8 builds
> Things that affect the bug:
>  * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log
>  * Redirecting all log output to a file using logback-test.xml
>  * Running Surefire with forkCount=0
>  * Running a subset of the tests (-Dtest=...)
>  * Pending Windows updates (I think, not sure about this one).
> Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never 
> seen it with redirecting log output (~ 10 builds). Redirecting sometimes 
> helps but not always.
> One thing which I notice is that one of the tests creates an ActiveMQ broker 
> and uses a shutdown hook to stop it. So I created a small test project which 
> demonstrates that Surefire will sometimes cut off stdout. I think that 
> happens because the main process kills the child after a timeout (correct?).
> So my guess would be that shutdown hooks can mess with the pipeline between 
> the surefire child VM and main Maven process. ActiveMQ might be worse since 
> it stops threads and execution pools (so the output comes slowly with a 
> couple of exceptions sprinkled in when one component loses connection because 
> another is shutting down).
> But now, it gets weird. When the build succeeds, it takes about ~5 minutes to 
> run 1028 tests. The log is 25 MB.
> When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) 
> and the log stops in the middle of a test but is also 25 MB.
> Some of the time discrepancy is probably because writing to a file is faster 
> than printing on a terminal. The strange part is that the log file is about 
> the same size but 30% of the tests haven't run. Most tests log a lot, do I 
> would expect to see a difference of at least a few MB. The Maven part (which 
> contains escape sequences, etc). is just 60 KB.
> Maybe the parent takes some part of the log output as "child terminated".
> I'm running out of ideas what to try next. I think a way to log the 
> communication between parent and child would help. Also the parent should 
> terminate the child and then read stdout until EOF to we can see anything 
> that happens afterwards.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ

[Adolfo Cia (Jira)]

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

Adolfo Cia commented on SUREFIRE-1631:
--

If I run:

mvn -Dtest=GetImageThumbnailMinuetTest clean test

on powershell I end up with the same issue after a few runs

> Forked VM terminated without properly saying goodbye with AciveMQ
> -
>
> Key: SUREFIRE-1631
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1631
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20.1, 2.22.0, 3.0.0-M2, 3.0.0-M1
>Reporter: Aaron Digulla
>Assignee: Tibor Digana
>Priority: Major
> Attachments: cmd.PNG, shurefire-shutdownhook-bug-0.0.1.zip
>
>
> I'm seeing spurious "The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?" messages when running unit tests in 
> a big multi-module project.
> OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of 
> Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191.
> I'm running Maven from the command line using MinTTY (Cygwin).
> Things I tried which have no effect:
>  * Reboot / Cold boot (happens first thing on Monday morning when I come into 
> the office and turn on my PC).
>  * More free memory (happens when I only have a single window open). I have 
> 16GB of RAM.
>  * Different terminal. I tried CMD prompt and urxvt (Cygwin/X).
>  * Different versions of the Surefire plugin or Maven
>  * Different JDK 8 builds
> Things that affect the bug:
>  * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log
>  * Redirecting all log output to a file using logback-test.xml
>  * Running Surefire with forkCount=0
>  * Running a subset of the tests (-Dtest=...)
>  * Pending Windows updates (I think, not sure about this one).
> Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never 
> seen it with redirecting log output (~ 10 builds). Redirecting sometimes 
> helps but not always.
> One thing which I notice is that one of the tests creates an ActiveMQ broker 
> and uses a shutdown hook to stop it. So I created a small test project which 
> demonstrates that Surefire will sometimes cut off stdout. I think that 
> happens because the main process kills the child after a timeout (correct?).
> So my guess would be that shutdown hooks can mess with the pipeline between 
> the surefire child VM and main Maven process. ActiveMQ might be worse since 
> it stops threads and execution pools (so the output comes slowly with a 
> couple of exceptions sprinkled in when one component loses connection because 
> another is shutting down).
> But now, it gets weird. When the build succeeds, it takes about ~5 minutes to 
> run 1028 tests. The log is 25 MB.
> When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) 
> and the log stops in the middle of a test but is also 25 MB.
> Some of the time discrepancy is probably because writing to a file is faster 
> than printing on a terminal. The strange part is that the log file is about 
> the same size but 30% of the tests haven't run. Most tests log a lot, do I 
> would expect to see a difference of at least a few MB. The Maven part (which 
> contains escape sequences, etc). is just 60 KB.
> Maybe the parent takes some part of the log output as "child terminated".
> I'm running out of ideas what to try next. I think a way to log the 
> communication between parent and child would help. Also the parent should 
> terminate the child and then read stdout until EOF to we can see anything 
> that happens afterwards.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ

[Adolfo Cia (Jira)]

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

Adolfo Cia commented on SUREFIRE-1631:
--

This issue, the "forked vm terminated.." , happens as well in our CI/CD 
pipeline. I don't know exactly the details of the environment, but I can look 
into it

> Forked VM terminated without properly saying goodbye with AciveMQ
> -
>
> Key: SUREFIRE-1631
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1631
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20.1, 2.22.0, 3.0.0-M2, 3.0.0-M1
>Reporter: Aaron Digulla
>Assignee: Tibor Digana
>Priority: Major
> Attachments: cmd.PNG, shurefire-shutdownhook-bug-0.0.1.zip
>
>
> I'm seeing spurious "The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?" messages when running unit tests in 
> a big multi-module project.
> OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of 
> Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191.
> I'm running Maven from the command line using MinTTY (Cygwin).
> Things I tried which have no effect:
>  * Reboot / Cold boot (happens first thing on Monday morning when I come into 
> the office and turn on my PC).
>  * More free memory (happens when I only have a single window open). I have 
> 16GB of RAM.
>  * Different terminal. I tried CMD prompt and urxvt (Cygwin/X).
>  * Different versions of the Surefire plugin or Maven
>  * Different JDK 8 builds
> Things that affect the bug:
>  * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log
>  * Redirecting all log output to a file using logback-test.xml
>  * Running Surefire with forkCount=0
>  * Running a subset of the tests (-Dtest=...)
>  * Pending Windows updates (I think, not sure about this one).
> Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never 
> seen it with redirecting log output (~ 10 builds). Redirecting sometimes 
> helps but not always.
> One thing which I notice is that one of the tests creates an ActiveMQ broker 
> and uses a shutdown hook to stop it. So I created a small test project which 
> demonstrates that Surefire will sometimes cut off stdout. I think that 
> happens because the main process kills the child after a timeout (correct?).
> So my guess would be that shutdown hooks can mess with the pipeline between 
> the surefire child VM and main Maven process. ActiveMQ might be worse since 
> it stops threads and execution pools (so the output comes slowly with a 
> couple of exceptions sprinkled in when one component loses connection because 
> another is shutting down).
> But now, it gets weird. When the build succeeds, it takes about ~5 minutes to 
> run 1028 tests. The log is 25 MB.
> When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) 
> and the log stops in the middle of a test but is also 25 MB.
> Some of the time discrepancy is probably because writing to a file is faster 
> than printing on a terminal. The strange part is that the log file is about 
> the same size but 30% of the tests haven't run. Most tests log a lot, do I 
> would expect to see a difference of at least a few MB. The Maven part (which 
> contains escape sequences, etc). is just 60 KB.
> Maybe the parent takes some part of the log output as "child terminated".
> I'm running out of ideas what to try next. I think a way to log the 
> communication between parent and child would help. Also the parent should 
> terminate the child and then read stdout until EOF to we can see anything 
> that happens afterwards.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ

[Tibor Digana (Jira)]

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

Tibor Digana commented on SUREFIRE-1631:


ok, so now it is obvious. Thx!

> Forked VM terminated without properly saying goodbye with AciveMQ
> -
>
> Key: SUREFIRE-1631
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1631
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20.1, 2.22.0, 3.0.0-M2, 3.0.0-M1
>Reporter: Aaron Digulla
>Assignee: Tibor Digana
>Priority: Major
> Attachments: cmd.PNG, shurefire-shutdownhook-bug-0.0.1.zip
>
>
> I'm seeing spurious "The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?" messages when running unit tests in 
> a big multi-module project.
> OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of 
> Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191.
> I'm running Maven from the command line using MinTTY (Cygwin).
> Things I tried which have no effect:
>  * Reboot / Cold boot (happens first thing on Monday morning when I come into 
> the office and turn on my PC).
>  * More free memory (happens when I only have a single window open). I have 
> 16GB of RAM.
>  * Different terminal. I tried CMD prompt and urxvt (Cygwin/X).
>  * Different versions of the Surefire plugin or Maven
>  * Different JDK 8 builds
> Things that affect the bug:
>  * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log
>  * Redirecting all log output to a file using logback-test.xml
>  * Running Surefire with forkCount=0
>  * Running a subset of the tests (-Dtest=...)
>  * Pending Windows updates (I think, not sure about this one).
> Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never 
> seen it with redirecting log output (~ 10 builds). Redirecting sometimes 
> helps but not always.
> One thing which I notice is that one of the tests creates an ActiveMQ broker 
> and uses a shutdown hook to stop it. So I created a small test project which 
> demonstrates that Surefire will sometimes cut off stdout. I think that 
> happens because the main process kills the child after a timeout (correct?).
> So my guess would be that shutdown hooks can mess with the pipeline between 
> the surefire child VM and main Maven process. ActiveMQ might be worse since 
> it stops threads and execution pools (so the output comes slowly with a 
> couple of exceptions sprinkled in when one component loses connection because 
> another is shutting down).
> But now, it gets weird. When the build succeeds, it takes about ~5 minutes to 
> run 1028 tests. The log is 25 MB.
> When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) 
> and the log stops in the middle of a test but is also 25 MB.
> Some of the time discrepancy is probably because writing to a file is faster 
> than printing on a terminal. The strange part is that the log file is about 
> the same size but 30% of the tests haven't run. Most tests log a lot, do I 
> would expect to see a difference of at least a few MB. The Maven part (which 
> contains escape sequences, etc). is just 60 KB.
> Maybe the parent takes some part of the log output as "child terminated".
> I'm running out of ideas what to try next. I think a way to log the 
> communication between parent and child would help. Also the parent should 
> terminate the child and then read stdout until EOF to we can see anything 
> that happens afterwards.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ

[Tibor Digana (Jira)]

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

Tibor Digana commented on SUREFIRE-1631:


[~adolfo.cia]
So the problem is that it is the Unix like console on Windows?
{{is not recognized as an internal or external command}}
I have similar result on Git Bash console:


{noformat}
C:\vcs\gitlab\AUDIT-3.0>CMD /A /X /C "wmic process where (ProcessId=14144) get 
CreationDate"
CMD /A /X /C "wmic process where (ProcessId=15672) get CreationDate"
CMD' is not recognized as an internal or external command,
operable program or batch file.
{noformat}




> Forked VM terminated without properly saying goodbye with AciveMQ
> -
>
> Key: SUREFIRE-1631
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1631
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20.1, 2.22.0, 3.0.0-M2, 3.0.0-M1
>Reporter: Aaron Digulla
>Assignee: Tibor Digana
>Priority: Major
> Attachments: cmd.PNG, shurefire-shutdownhook-bug-0.0.1.zip
>
>
> I'm seeing spurious "The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?" messages when running unit tests in 
> a big multi-module project.
> OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of 
> Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191.
> I'm running Maven from the command line using MinTTY (Cygwin).
> Things I tried which have no effect:
>  * Reboot / Cold boot (happens first thing on Monday morning when I come into 
> the office and turn on my PC).
>  * More free memory (happens when I only have a single window open). I have 
> 16GB of RAM.
>  * Different terminal. I tried CMD prompt and urxvt (Cygwin/X).
>  * Different versions of the Surefire plugin or Maven
>  * Different JDK 8 builds
> Things that affect the bug:
>  * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log
>  * Redirecting all log output to a file using logback-test.xml
>  * Running Surefire with forkCount=0
>  * Running a subset of the tests (-Dtest=...)
>  * Pending Windows updates (I think, not sure about this one).
> Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never 
> seen it with redirecting log output (~ 10 builds). Redirecting sometimes 
> helps but not always.
> One thing which I notice is that one of the tests creates an ActiveMQ broker 
> and uses a shutdown hook to stop it. So I created a small test project which 
> demonstrates that Surefire will sometimes cut off stdout. I think that 
> happens because the main process kills the child after a timeout (correct?).
> So my guess would be that shutdown hooks can mess with the pipeline between 
> the surefire child VM and main Maven process. ActiveMQ might be worse since 
> it stops threads and execution pools (so the output comes slowly with a 
> couple of exceptions sprinkled in when one component loses connection because 
> another is shutting down).
> But now, it gets weird. When the build succeeds, it takes about ~5 minutes to 
> run 1028 tests. The log is 25 MB.
> When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) 
> and the log stops in the middle of a test but is also 25 MB.
> Some of the time discrepancy is probably because writing to a file is faster 
> than printing on a terminal. The strange part is that the log file is about 
> the same size but 30% of the tests haven't run. Most tests log a lot, do I 
> would expect to see a difference of at least a few MB. The Maven part (which 
> contains escape sequences, etc). is just 60 KB.
> Maybe the parent takes some part of the log output as "child terminated".
> I'm running out of ideas what to try next. I think a way to log the 
> communication between parent and child would help. Also the parent should 
> terminate the child and then read stdout until EOF to we can see anything 
> that happens afterwards.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ

[Adolfo Cia (Jira)]

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

Adolfo Cia commented on SUREFIRE-1631:
--

Here is on cmd windows console:

!cmd.PNG!

> Forked VM terminated without properly saying goodbye with AciveMQ
> -
>
> Key: SUREFIRE-1631
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1631
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20.1, 2.22.0, 3.0.0-M2, 3.0.0-M1
>Reporter: Aaron Digulla
>Assignee: Tibor Digana
>Priority: Major
> Attachments: cmd.PNG, shurefire-shutdownhook-bug-0.0.1.zip
>
>
> I'm seeing spurious "The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?" messages when running unit tests in 
> a big multi-module project.
> OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of 
> Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191.
> I'm running Maven from the command line using MinTTY (Cygwin).
> Things I tried which have no effect:
>  * Reboot / Cold boot (happens first thing on Monday morning when I come into 
> the office and turn on my PC).
>  * More free memory (happens when I only have a single window open). I have 
> 16GB of RAM.
>  * Different terminal. I tried CMD prompt and urxvt (Cygwin/X).
>  * Different versions of the Surefire plugin or Maven
>  * Different JDK 8 builds
> Things that affect the bug:
>  * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log
>  * Redirecting all log output to a file using logback-test.xml
>  * Running Surefire with forkCount=0
>  * Running a subset of the tests (-Dtest=...)
>  * Pending Windows updates (I think, not sure about this one).
> Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never 
> seen it with redirecting log output (~ 10 builds). Redirecting sometimes 
> helps but not always.
> One thing which I notice is that one of the tests creates an ActiveMQ broker 
> and uses a shutdown hook to stop it. So I created a small test project which 
> demonstrates that Surefire will sometimes cut off stdout. I think that 
> happens because the main process kills the child after a timeout (correct?).
> So my guess would be that shutdown hooks can mess with the pipeline between 
> the surefire child VM and main Maven process. ActiveMQ might be worse since 
> it stops threads and execution pools (so the output comes slowly with a 
> couple of exceptions sprinkled in when one component loses connection because 
> another is shutting down).
> But now, it gets weird. When the build succeeds, it takes about ~5 minutes to 
> run 1028 tests. The log is 25 MB.
> When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) 
> and the log stops in the middle of a test but is also 25 MB.
> Some of the time discrepancy is probably because writing to a file is faster 
> than printing on a terminal. The strange part is that the log file is about 
> the same size but 30% of the tests haven't run. Most tests log a lot, do I 
> would expect to see a difference of at least a few MB. The Maven part (which 
> contains escape sequences, etc). is just 60 KB.
> Maybe the parent takes some part of the log output as "child terminated".
> I'm running out of ideas what to try next. I think a way to log the 
> communication between parent and child would help. Also the parent should 
> terminate the child and then read stdout until EOF to we can see anything 
> that happens afterwards.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ

[Adolfo Cia (Jira)]

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

Adolfo Cia updated SUREFIRE-1631:
-
Attachment: cmd.PNG

> Forked VM terminated without properly saying goodbye with AciveMQ
> -
>
> Key: SUREFIRE-1631
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1631
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20.1, 2.22.0, 3.0.0-M2, 3.0.0-M1
>Reporter: Aaron Digulla
>Assignee: Tibor Digana
>Priority: Major
> Attachments: cmd.PNG, shurefire-shutdownhook-bug-0.0.1.zip
>
>
> I'm seeing spurious "The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?" messages when running unit tests in 
> a big multi-module project.
> OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of 
> Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191.
> I'm running Maven from the command line using MinTTY (Cygwin).
> Things I tried which have no effect:
>  * Reboot / Cold boot (happens first thing on Monday morning when I come into 
> the office and turn on my PC).
>  * More free memory (happens when I only have a single window open). I have 
> 16GB of RAM.
>  * Different terminal. I tried CMD prompt and urxvt (Cygwin/X).
>  * Different versions of the Surefire plugin or Maven
>  * Different JDK 8 builds
> Things that affect the bug:
>  * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log
>  * Redirecting all log output to a file using logback-test.xml
>  * Running Surefire with forkCount=0
>  * Running a subset of the tests (-Dtest=...)
>  * Pending Windows updates (I think, not sure about this one).
> Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never 
> seen it with redirecting log output (~ 10 builds). Redirecting sometimes 
> helps but not always.
> One thing which I notice is that one of the tests creates an ActiveMQ broker 
> and uses a shutdown hook to stop it. So I created a small test project which 
> demonstrates that Surefire will sometimes cut off stdout. I think that 
> happens because the main process kills the child after a timeout (correct?).
> So my guess would be that shutdown hooks can mess with the pipeline between 
> the surefire child VM and main Maven process. ActiveMQ might be worse since 
> it stops threads and execution pools (so the output comes slowly with a 
> couple of exceptions sprinkled in when one component loses connection because 
> another is shutting down).
> But now, it gets weird. When the build succeeds, it takes about ~5 minutes to 
> run 1028 tests. The log is 25 MB.
> When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) 
> and the log stops in the middle of a test but is also 25 MB.
> Some of the time discrepancy is probably because writing to a file is faster 
> than printing on a terminal. The strange part is that the log file is about 
> the same size but 30% of the tests haven't run. Most tests log a lot, do I 
> would expect to see a difference of at least a few MB. The Maven part (which 
> contains escape sequences, etc). is just 60 KB.
> Maybe the parent takes some part of the log output as "child terminated".
> I'm running out of ideas what to try next. I think a way to log the 
> communication between parent and child would help. Also the parent should 
> terminate the child and then read stdout until EOF to we can see anything 
> that happens afterwards.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-6771) Fix license issues on binary distribution

[Hudson (Jira)]

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

Hudson commented on MNG-6771:
-

Build succeeded in Jenkins: Maven TLP » maven » MNG-6771 #3

See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6771/3/

> Fix license issues on binary distribution
> -
>
> Key: MNG-6771
> URL: https://issues.apache.org/jira/browse/MNG-6771
> Project: Maven
>  Issue Type: Bug
>  Components: General
>Affects Versions: 3.6.2
>Reporter: Vladimir Sitnikov
>Assignee: Enrico Olivelli
>Priority: Major
>  Labels: licenses
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Please feel free to adjust the priority, however 
> [http://www.apache.org/legal/release-policy.html#licensing] says that license 
> clearance is a must, thus I report this as a Blocker.
> {quote}Every ASF release MUST comply with ASF licensing policy. This 
> requirement is of utmost importance
> {quote}
> I downloaded apache-maven-3.6.2-bin.zip, and I see the following issues with 
> it (note: there might be more):
> h2. 1) jcl-over-slf4j:1.7.25
> in apache-maven-3.6.2/LICENSE:
> {quote} - JCL 1.2 implemented over SLF4J 
> ([http://www.slf4j.org|http://www.slf4j.org/]) 
> org.slf4j:jcl-over-slf4j:jar:1.7.25
>  License: MIT License (MIT) 
> [http://www.opensource.org/licenses/mit-license.php] 
> (lib/jcl-over-slf4j.license){quote}
> The license for the artifact is most likely Apache 2.0 rather than MIT: 
> [https://github.com/qos-ch/slf4j/tree/master/jcl-over-slf4j]
> h2. 2) slf4j-api:1.7.25
> in apache-maven-3.6.2/LICENSE:
> {quote} - SLF4J API Module ([http://www.slf4j.org|http://www.slf4j.org/]) 
> org.slf4j:slf4j-api:jar:1.7.25
>  License: MIT License (MIT) 
> [http://www.opensource.org/licenses/mit-license.php] 
> (lib/slf4j-api.license){quote}
> Maven does not comply with SLF4j license.
>  Here's license for SLF4j: [https://www.slf4j.org/license.html]
>  It requires to include slf4j copyright notice, however, Maven fails to do 
> that
> h2. 3) MIT license
> [http://www.opensource.org/licenses/mit-license.php] must not be used as it 
> almost never points to a true license. It is extremely unlucky that someone 
> would copyright their work as "Copyright (c)  "
> h2. 4) org.eclipse.sisu.inject:0.3.3
> in apache-maven-3.6.2/LICENSE:
> {quote} - org.eclipse.sisu.inject 
> ([http://www.eclipse.org/sisu/org.eclipse.sisu.inject/]) 
> org.eclipse.sisu:org.eclipse.sisu.inject:eclipse-plugin:0.3.3
>  License: Eclipse Public License, Version 1.0 (EPL-1.0) 
> [http://www.eclipse.org/legal/epl-v10.html] 
> (lib/org.eclipse.sisu.inject.license){quote}
> The link to eclipse.org/sisu responds with 404.
> sisu might have their own copyright notices that should be retained, however 
> Maven re-distributes none of them (org.eclipse.sisu.inject.site-0.3.3.zip has 
> notice.html file which is not present in Maven re-distribution)
> h2. 5) ASM in org.eclipse.sisu.inject-0.3.3.jar
> lib/org.eclipse.sisu.inject-0.3.3.jar bundles ASM. ASM is MIT licensed, thus 
> every re-distribution MUST retain ASM copyright notice.
>  Maven re-distributes ASM and fails to comply with ASM license.
> h2. 6) jsoup in wagon-http-3.3.3-shaded.jar
> lib/wagon-http-3.3.3-shaded.jar bundles jsoup ([https://jsoup.org/license]) 
> which is MIT-licensed. Maven fails to comply with jsoup license.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-6778) Use https for schemaLocations

[Hudson (Jira)]

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

Hudson commented on MNG-6778:
-

Build succeeded in Jenkins: Maven TLP » maven » MNG-6771 #3

See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6771/3/

> Use https for schemaLocations
> -
>
> Key: MNG-6778
> URL: https://issues.apache.org/jira/browse/MNG-6778
> Project: Maven
>  Issue Type: Improvement
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
>  Labels: up-for-grabs
> Fix For: 3.6.3
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> All poms start with the following roottag:
> {code:xml}
> http://maven.apache.org/POM/4.0.0; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; 
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> {code}
> The schemaLocation VALUE should be updated to 
> {{https://maven.apache.org/xsd/maven-4.0.0.xsd}}; the key is just a constant 
> String, even though it looks like a URL, better to keep this the same.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-6789) Make Maven distribution build Reproducible

[Hudson (Jira)]

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

Hudson commented on MNG-6789:
-

Build succeeded in Jenkins: Maven TLP » maven » MNG-6771 #3

See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6771/3/

> Make Maven distribution build Reproducible
> --
>
> Key: MNG-6789
> URL: https://issues.apache.org/jira/browse/MNG-6789
> Project: Maven
>  Issue Type: Task
>  Components: Bootstrap  Build
>Affects Versions: 3.6.2
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 3.6.3
>
>
> with [Maven native Reproducible 
> Builds|https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318]
>  near available, it would be great to have Maven itself being the first Maven 
> project that gets Reproducible Builds
> there is already a proof of concept available in reproducible branch: 
> https://github.com/apache/maven/tree/reproducible with corresponding Jenkins 
> build 
> https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven/job/reproducible/
> once maven-jar-plugin, maven-assembly-plugin and maven-source-plugin have a 
> reproducible release available, the last 2 plugins that bring non 
> reproducible result in this build are plexus-component-metadata 2.0.0 and 
> sisu-maven-plugin



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ

[Adolfo Cia (Jira)]

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

Adolfo Cia commented on SUREFIRE-1631:
--

that was the only dump file in target/surefire-reports

yes I ran it on mintty (git bash console for windows), I'll try it on windows 
cmd console.

the process IS alive, is outlook app. I've checked that.

> Forked VM terminated without properly saying goodbye with AciveMQ
> -
>
> Key: SUREFIRE-1631
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1631
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20.1, 2.22.0, 3.0.0-M2, 3.0.0-M1
>Reporter: Aaron Digulla
>Assignee: Tibor Digana
>Priority: Major
> Attachments: shurefire-shutdownhook-bug-0.0.1.zip
>
>
> I'm seeing spurious "The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?" messages when running unit tests in 
> a big multi-module project.
> OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of 
> Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191.
> I'm running Maven from the command line using MinTTY (Cygwin).
> Things I tried which have no effect:
>  * Reboot / Cold boot (happens first thing on Monday morning when I come into 
> the office and turn on my PC).
>  * More free memory (happens when I only have a single window open). I have 
> 16GB of RAM.
>  * Different terminal. I tried CMD prompt and urxvt (Cygwin/X).
>  * Different versions of the Surefire plugin or Maven
>  * Different JDK 8 builds
> Things that affect the bug:
>  * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log
>  * Redirecting all log output to a file using logback-test.xml
>  * Running Surefire with forkCount=0
>  * Running a subset of the tests (-Dtest=...)
>  * Pending Windows updates (I think, not sure about this one).
> Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never 
> seen it with redirecting log output (~ 10 builds). Redirecting sometimes 
> helps but not always.
> One thing which I notice is that one of the tests creates an ActiveMQ broker 
> and uses a shutdown hook to stop it. So I created a small test project which 
> demonstrates that Surefire will sometimes cut off stdout. I think that 
> happens because the main process kills the child after a timeout (correct?).
> So my guess would be that shutdown hooks can mess with the pipeline between 
> the surefire child VM and main Maven process. ActiveMQ might be worse since 
> it stops threads and execution pools (so the output comes slowly with a 
> couple of exceptions sprinkled in when one component loses connection because 
> another is shutting down).
> But now, it gets weird. When the build succeeds, it takes about ~5 minutes to 
> run 1028 tests. The log is 25 MB.
> When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) 
> and the log stops in the middle of a test but is also 25 MB.
> Some of the time discrepancy is probably because writing to a file is faster 
> than printing on a terminal. The strange part is that the log file is about 
> the same size but 30% of the tests haven't run. Most tests log a lot, do I 
> would expect to see a difference of at least a few MB. The Maven part (which 
> contains escape sequences, etc). is just 60 KB.
> Maybe the parent takes some part of the log output as "child terminated".
> I'm running out of ideas what to try next. I think a way to log the 
> communication between parent and child would help. Also the parent should 
> terminate the child and then read stdout until EOF to we can see anything 
> that happens afterwards.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-6799) avoid model interpolation instability risk: ensure StringVisitorModelInterpolator replaces StringSearchModelInterpolator

[Hudson (Jira)]

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

Hudson commented on MNG-6799:
-

Build succeeded in Jenkins: Maven TLP » maven » MNG-6771 #3

See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6771/3/

> avoid model interpolation instability risk: ensure 
> StringVisitorModelInterpolator replaces StringSearchModelInterpolator
> 
>
> Key: MNG-6799
> URL: https://issues.apache.org/jira/browse/MNG-6799
> Project: Maven
>  Issue Type: Improvement
>  Components: Inheritance and Interpolation
>Affects Versions: 3.6.2
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 3.6.3
>
>
> as discovered recently and [shared on dev 
> ML|https://lists.apache.org/thread.html/efab59150580f27de386386730e3816188ea2d27faa5fa4c96934149@%3Cdev.maven.apache.org%3E],
>  in maven-model-builder, 
> [StringVisitorModelInterpolator|http://maven.apache.org/ref/3.6.2/maven-model-builder/apidocs/org/apache/maven/model/interpolation/StringVisitorModelInterpolator.html]
>  introduced by MNG-6697 in Maven 3.6.2 is meant to replace 
> [StringSearchModelInterpolator|http://maven.apache.org/ref/3.6.2/maven-model-builder/apidocs/org/apache/maven/model/interpolation/StringSearchModelInterpolator.html]
> but currently, both can be injected and the selection of one against the 
> other depends on the order of generated CDI descriptors: if you're lucky, 
> StringVisitorModelInterpolator appear first, but if you're not, 
> StringSearchModelInterpolator will do instead.
> In addition, with Reproducible Builds being introduced in MNG-6789, the order 
> that is introduced is String lexical order: StringSearchModelInterpolator is 
> then before StringVisitorModelInterpolator then with Reproducible Builds we 
> get the unwanted result in a reproducible way...
> we need to ensure that StringVisitorModelInterpolator will be used instead of 
> StringSearchModelInterpolator



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ

[Tibor Digana (Jira)]

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

Tibor Digana commented on SUREFIRE-1631:


The ProcessId was alive?

> Forked VM terminated without properly saying goodbye with AciveMQ
> -
>
> Key: SUREFIRE-1631
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1631
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20.1, 2.22.0, 3.0.0-M2, 3.0.0-M1
>Reporter: Aaron Digulla
>Assignee: Tibor Digana
>Priority: Major
> Attachments: shurefire-shutdownhook-bug-0.0.1.zip
>
>
> I'm seeing spurious "The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?" messages when running unit tests in 
> a big multi-module project.
> OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of 
> Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191.
> I'm running Maven from the command line using MinTTY (Cygwin).
> Things I tried which have no effect:
>  * Reboot / Cold boot (happens first thing on Monday morning when I come into 
> the office and turn on my PC).
>  * More free memory (happens when I only have a single window open). I have 
> 16GB of RAM.
>  * Different terminal. I tried CMD prompt and urxvt (Cygwin/X).
>  * Different versions of the Surefire plugin or Maven
>  * Different JDK 8 builds
> Things that affect the bug:
>  * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log
>  * Redirecting all log output to a file using logback-test.xml
>  * Running Surefire with forkCount=0
>  * Running a subset of the tests (-Dtest=...)
>  * Pending Windows updates (I think, not sure about this one).
> Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never 
> seen it with redirecting log output (~ 10 builds). Redirecting sometimes 
> helps but not always.
> One thing which I notice is that one of the tests creates an ActiveMQ broker 
> and uses a shutdown hook to stop it. So I created a small test project which 
> demonstrates that Surefire will sometimes cut off stdout. I think that 
> happens because the main process kills the child after a timeout (correct?).
> So my guess would be that shutdown hooks can mess with the pipeline between 
> the surefire child VM and main Maven process. ActiveMQ might be worse since 
> it stops threads and execution pools (so the output comes slowly with a 
> couple of exceptions sprinkled in when one component loses connection because 
> another is shutting down).
> But now, it gets weird. When the build succeeds, it takes about ~5 minutes to 
> run 1028 tests. The log is 25 MB.
> When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) 
> and the log stops in the middle of a test but is also 25 MB.
> Some of the time discrepancy is probably because writing to a file is faster 
> than printing on a terminal. The strange part is that the log file is about 
> the same size but 30% of the tests haven't run. Most tests log a lot, do I 
> would expect to see a difference of at least a few MB. The Maven part (which 
> contains escape sequences, etc). is just 60 KB.
> Maybe the parent takes some part of the log output as "child terminated".
> I'm running out of ideas what to try next. I think a way to log the 
> communication between parent and child would help. Also the parent should 
> terminate the child and then read stdout until EOF to we can see anything 
> that happens afterwards.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ

[Tibor Digana (Jira)]

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

Tibor Digana commented on SUREFIRE-1631:


So you run it in Git Bash console?
What happens if you run it in normal Windows CMD console?

> Forked VM terminated without properly saying goodbye with AciveMQ
> -
>
> Key: SUREFIRE-1631
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1631
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20.1, 2.22.0, 3.0.0-M2, 3.0.0-M1
>Reporter: Aaron Digulla
>Assignee: Tibor Digana
>Priority: Major
> Attachments: shurefire-shutdownhook-bug-0.0.1.zip
>
>
> I'm seeing spurious "The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?" messages when running unit tests in 
> a big multi-module project.
> OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of 
> Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191.
> I'm running Maven from the command line using MinTTY (Cygwin).
> Things I tried which have no effect:
>  * Reboot / Cold boot (happens first thing on Monday morning when I come into 
> the office and turn on my PC).
>  * More free memory (happens when I only have a single window open). I have 
> 16GB of RAM.
>  * Different terminal. I tried CMD prompt and urxvt (Cygwin/X).
>  * Different versions of the Surefire plugin or Maven
>  * Different JDK 8 builds
> Things that affect the bug:
>  * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log
>  * Redirecting all log output to a file using logback-test.xml
>  * Running Surefire with forkCount=0
>  * Running a subset of the tests (-Dtest=...)
>  * Pending Windows updates (I think, not sure about this one).
> Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never 
> seen it with redirecting log output (~ 10 builds). Redirecting sometimes 
> helps but not always.
> One thing which I notice is that one of the tests creates an ActiveMQ broker 
> and uses a shutdown hook to stop it. So I created a small test project which 
> demonstrates that Surefire will sometimes cut off stdout. I think that 
> happens because the main process kills the child after a timeout (correct?).
> So my guess would be that shutdown hooks can mess with the pipeline between 
> the surefire child VM and main Maven process. ActiveMQ might be worse since 
> it stops threads and execution pools (so the output comes slowly with a 
> couple of exceptions sprinkled in when one component loses connection because 
> another is shutting down).
> But now, it gets weird. When the build succeeds, it takes about ~5 minutes to 
> run 1028 tests. The log is 25 MB.
> When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) 
> and the log stops in the middle of a test but is also 25 MB.
> Some of the time discrepancy is probably because writing to a file is faster 
> than printing on a terminal. The strange part is that the log file is about 
> the same size but 30% of the tests haven't run. Most tests log a lot, do I 
> would expect to see a difference of at least a few MB. The Maven part (which 
> contains escape sequences, etc). is just 60 KB.
> Maybe the parent takes some part of the log output as "child terminated".
> I'm running out of ideas what to try next. I think a way to log the 
> communication between parent and child would help. Also the parent should 
> terminate the child and then read stdout until EOF to we can see anything 
> that happens afterwards.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ

[Adolfo Cia (Jira)]

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

Adolfo Cia commented on SUREFIRE-1631:
--

[~tibordigana]

Here is the command you told me to execute:
{code:java}
adolfo.cia@LAP0462 MINGW64 
/c/liberty_development/workspaces/services/ltl-java-linehauloperations-ensemble 
(development)
$ CMD /A /X /C "wmic process where (ProcessId=15672) get CreationDate"
Microsoft Windows [Version 10.0.18362.418]
(c) 2019 Microsoft Corporation. All rights 
reserved.C:\liberty_development\workspaces\services\ltl-java-linehauloperations-ensemble>''
 is not recognized as an internal or external command,
operable program or batch 
file.C:\liberty_development\workspaces\services\ltl-java-linehauloperations-ensemble>wmic
 process where (ProcessId=15672) get CreationDate
wmic process where (ProcessId=15672) get CreationDate
CreationDate
2019085452.926420-180

{code}

> Forked VM terminated without properly saying goodbye with AciveMQ
> -
>
> Key: SUREFIRE-1631
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1631
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20.1, 2.22.0, 3.0.0-M2, 3.0.0-M1
>Reporter: Aaron Digulla
>Assignee: Tibor Digana
>Priority: Major
> Attachments: shurefire-shutdownhook-bug-0.0.1.zip
>
>
> I'm seeing spurious "The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?" messages when running unit tests in 
> a big multi-module project.
> OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of 
> Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191.
> I'm running Maven from the command line using MinTTY (Cygwin).
> Things I tried which have no effect:
>  * Reboot / Cold boot (happens first thing on Monday morning when I come into 
> the office and turn on my PC).
>  * More free memory (happens when I only have a single window open). I have 
> 16GB of RAM.
>  * Different terminal. I tried CMD prompt and urxvt (Cygwin/X).
>  * Different versions of the Surefire plugin or Maven
>  * Different JDK 8 builds
> Things that affect the bug:
>  * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log
>  * Redirecting all log output to a file using logback-test.xml
>  * Running Surefire with forkCount=0
>  * Running a subset of the tests (-Dtest=...)
>  * Pending Windows updates (I think, not sure about this one).
> Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never 
> seen it with redirecting log output (~ 10 builds). Redirecting sometimes 
> helps but not always.
> One thing which I notice is that one of the tests creates an ActiveMQ broker 
> and uses a shutdown hook to stop it. So I created a small test project which 
> demonstrates that Surefire will sometimes cut off stdout. I think that 
> happens because the main process kills the child after a timeout (correct?).
> So my guess would be that shutdown hooks can mess with the pipeline between 
> the surefire child VM and main Maven process. ActiveMQ might be worse since 
> it stops threads and execution pools (so the output comes slowly with a 
> couple of exceptions sprinkled in when one component loses connection because 
> another is shutting down).
> But now, it gets weird. When the build succeeds, it takes about ~5 minutes to 
> run 1028 tests. The log is 25 MB.
> When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) 
> and the log stops in the middle of a test but is also 25 MB.
> Some of the time discrepancy is probably because writing to a file is faster 
> than printing on a terminal. The strange part is that the log file is about 
> the same size but 30% of the tests haven't run. Most tests log a lot, do I 
> would expect to see a difference of at least a few MB. The Maven part (which 
> contains escape sequences, etc). is just 60 KB.
> Maybe the parent takes some part of the log output as "child terminated".
> I'm running out of ideas what to try next. I think a way to log the 
> communication between parent and child would help. Also the parent should 
> terminate the child and then read stdout until EOF to we can see anything 
> that happens afterwards.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ

[Tibor Digana (Jira)]

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

Tibor Digana commented on SUREFIRE-1631:


Is there only one dump file?

> Forked VM terminated without properly saying goodbye with AciveMQ
> -
>
> Key: SUREFIRE-1631
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1631
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20.1, 2.22.0, 3.0.0-M2, 3.0.0-M1
>Reporter: Aaron Digulla
>Assignee: Tibor Digana
>Priority: Major
> Attachments: shurefire-shutdownhook-bug-0.0.1.zip
>
>
> I'm seeing spurious "The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?" messages when running unit tests in 
> a big multi-module project.
> OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of 
> Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191.
> I'm running Maven from the command line using MinTTY (Cygwin).
> Things I tried which have no effect:
>  * Reboot / Cold boot (happens first thing on Monday morning when I come into 
> the office and turn on my PC).
>  * More free memory (happens when I only have a single window open). I have 
> 16GB of RAM.
>  * Different terminal. I tried CMD prompt and urxvt (Cygwin/X).
>  * Different versions of the Surefire plugin or Maven
>  * Different JDK 8 builds
> Things that affect the bug:
>  * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log
>  * Redirecting all log output to a file using logback-test.xml
>  * Running Surefire with forkCount=0
>  * Running a subset of the tests (-Dtest=...)
>  * Pending Windows updates (I think, not sure about this one).
> Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never 
> seen it with redirecting log output (~ 10 builds). Redirecting sometimes 
> helps but not always.
> One thing which I notice is that one of the tests creates an ActiveMQ broker 
> and uses a shutdown hook to stop it. So I created a small test project which 
> demonstrates that Surefire will sometimes cut off stdout. I think that 
> happens because the main process kills the child after a timeout (correct?).
> So my guess would be that shutdown hooks can mess with the pipeline between 
> the surefire child VM and main Maven process. ActiveMQ might be worse since 
> it stops threads and execution pools (so the output comes slowly with a 
> couple of exceptions sprinkled in when one component loses connection because 
> another is shutting down).
> But now, it gets weird. When the build succeeds, it takes about ~5 minutes to 
> run 1028 tests. The log is 25 MB.
> When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) 
> and the log stops in the middle of a test but is also 25 MB.
> Some of the time discrepancy is probably because writing to a file is faster 
> than printing on a terminal. The strange part is that the log file is about 
> the same size but 30% of the tests haven't run. Most tests log a lot, do I 
> would expect to see a difference of at least a few MB. The Maven part (which 
> contains escape sequences, etc). is just 60 KB.
> Maybe the parent takes some part of the log output as "child terminated".
> I'm running out of ideas what to try next. I think a way to log the 
> communication between parent and child would help. Also the parent should 
> terminate the child and then read stdout until EOF to we can see anything 
> that happens afterwards.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ

[Adolfo Cia (Jira)]

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

Adolfo Cia edited comment on SUREFIRE-1631 at 11/11/19 1:21 PM:


[~tibordigana]

Ok, snapshot 3.0.0 didn't work (failed the fifth time I execute it):
{code:java}
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time:  9.047 s
[INFO] Finished at: 2019-11-11T10:15:47-03:00
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-SNAPSHOT:test 
(default-test) on project ltl-java-linehauloperations-ensemble: There are test 
failures.
[ERROR]
[ERROR] Please refer to 
C:\liberty_development\workspaces\services\ltl-java-linehauloperations-ensemble\target\surefire-reports
 for the individual test results.
[ERROR] Please refer to dump files (if any exist) [date].dump, 
[date]-jvmRun[N].dump and [date].dumpstream.
[ERROR] The forked VM terminated without properly saying goodbye. VM crash or 
System.exit called?
[ERROR] Command was cmd.exe /X /C 
"C:\liberty_development\wlp\java\java\jre\bin\java 
-javaagent:C:\Users\adolfo.cia\.m2\repository/org/jmockit/jmockit/1.48/jmockit-1.48.jar
 -jar 
C:\Users\adolfo.cia\AppData\Local\Temp\surefire1699052172262397174\surefirebooter94309476510590017.jar
 C:\Users\adolfo.cia\AppData\Local\Temp\surefire1699052172262397174 
2019-11-11T10-15-44_326-jvmRun1 surefire4984701455985067123tmp 
surefire_01067224024401515361tmp"
[ERROR] Error occurred in starting fork, check output in log
[ERROR] Process Exit Code: 1
[ERROR] Crashed tests:
[ERROR] 
com.xpo.ltl.linehauloperations.service.ejb.v1.GetImageThumbnailMinuetTest
[ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: The 
forked VM terminated without properly saying goodbye. VM crash or System.exit 
called?
[ERROR] Command was cmd.exe /X /C 
"C:\liberty_development\wlp\java\java\jre\bin\java 
-javaagent:C:\Users\adolfo.cia\.m2\repository/org/jmockit/jmockit/1.48/jmockit-1.48.jar
 -jar 
C:\Users\adolfo.cia\AppData\Local\Temp\surefire1699052172262397174\surefirebooter94309476510590017.jar
 C:\Users\adolfo.cia\AppData\Local\Temp\surefire1699052172262397174 
2019-11-11T10-15-44_326-jvmRun1 surefire4984701455985067123tmp 
surefire_01067224024401515361tmp"
[ERROR] Error occurred in starting fork, check output in log
[ERROR] Process Exit Code: 1
[ERROR] Crashed tests:
[ERROR] 
com.xpo.ltl.linehauloperations.service.ejb.v1.GetImageThumbnailMinuetTest
[ERROR] at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:690)
[ERROR] at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:285)
[ERROR] at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:248)
[ERROR] at 
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1213)
[ERROR] at 
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1059)
[ERROR] at 
org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:886)
[ERROR] at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
[ERROR] at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
[ERROR] at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
[ERROR] at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
[ERROR] at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
[ERROR] at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
[ERROR] at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
[ERROR] at 
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
[ERROR] at 
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
[ERROR] at 
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
[ERROR] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
[ERROR] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:956)
[ERROR] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
[ERROR] at org.apache.maven.cli.MavenCli.main(MavenCli.java:192)
[ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[ERROR] at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)

[jira] [Commented] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ

[Adolfo Cia (Jira)]

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

Adolfo Cia commented on SUREFIRE-1631:
--

[~tibordigana]

Ok, snapshot 3.0.0 didn't work:
{code:java}
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time:  9.047 s
[INFO] Finished at: 2019-11-11T10:15:47-03:00
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-SNAPSHOT:test 
(default-test) on project ltl-java-linehauloperations-ensemble: There are test 
failures.
[ERROR]
[ERROR] Please refer to 
C:\liberty_development\workspaces\services\ltl-java-linehauloperations-ensemble\target\surefire-reports
 for the individual test results.
[ERROR] Please refer to dump files (if any exist) [date].dump, 
[date]-jvmRun[N].dump and [date].dumpstream.
[ERROR] The forked VM terminated without properly saying goodbye. VM crash or 
System.exit called?
[ERROR] Command was cmd.exe /X /C 
"C:\liberty_development\wlp\java\java\jre\bin\java 
-javaagent:C:\Users\adolfo.cia\.m2\repository/org/jmockit/jmockit/1.48/jmockit-1.48.jar
 -jar 
C:\Users\adolfo.cia\AppData\Local\Temp\surefire1699052172262397174\surefirebooter94309476510590017.jar
 C:\Users\adolfo.cia\AppData\Local\Temp\surefire1699052172262397174 
2019-11-11T10-15-44_326-jvmRun1 surefire4984701455985067123tmp 
surefire_01067224024401515361tmp"
[ERROR] Error occurred in starting fork, check output in log
[ERROR] Process Exit Code: 1
[ERROR] Crashed tests:
[ERROR] 
com.xpo.ltl.linehauloperations.service.ejb.v1.GetImageThumbnailMinuetTest
[ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: The 
forked VM terminated without properly saying goodbye. VM crash or System.exit 
called?
[ERROR] Command was cmd.exe /X /C 
"C:\liberty_development\wlp\java\java\jre\bin\java 
-javaagent:C:\Users\adolfo.cia\.m2\repository/org/jmockit/jmockit/1.48/jmockit-1.48.jar
 -jar 
C:\Users\adolfo.cia\AppData\Local\Temp\surefire1699052172262397174\surefirebooter94309476510590017.jar
 C:\Users\adolfo.cia\AppData\Local\Temp\surefire1699052172262397174 
2019-11-11T10-15-44_326-jvmRun1 surefire4984701455985067123tmp 
surefire_01067224024401515361tmp"
[ERROR] Error occurred in starting fork, check output in log
[ERROR] Process Exit Code: 1
[ERROR] Crashed tests:
[ERROR] 
com.xpo.ltl.linehauloperations.service.ejb.v1.GetImageThumbnailMinuetTest
[ERROR] at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:690)
[ERROR] at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:285)
[ERROR] at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:248)
[ERROR] at 
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1213)
[ERROR] at 
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1059)
[ERROR] at 
org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:886)
[ERROR] at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
[ERROR] at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
[ERROR] at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
[ERROR] at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
[ERROR] at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
[ERROR] at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
[ERROR] at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
[ERROR] at 
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
[ERROR] at 
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
[ERROR] at 
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
[ERROR] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
[ERROR] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:956)
[ERROR] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
[ERROR] at org.apache.maven.cli.MavenCli.main(MavenCli.java:192)
[ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[ERROR] at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
[ERROR] at 

[jira] [Commented] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ

[Tibor Digana (Jira)]

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

Tibor Digana commented on SUREFIRE-1631:


The same console which you used for the Maven.

> Forked VM terminated without properly saying goodbye with AciveMQ
> -
>
> Key: SUREFIRE-1631
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1631
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20.1, 2.22.0, 3.0.0-M2, 3.0.0-M1
>Reporter: Aaron Digulla
>Assignee: Tibor Digana
>Priority: Major
> Attachments: shurefire-shutdownhook-bug-0.0.1.zip
>
>
> I'm seeing spurious "The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?" messages when running unit tests in 
> a big multi-module project.
> OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of 
> Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191.
> I'm running Maven from the command line using MinTTY (Cygwin).
> Things I tried which have no effect:
>  * Reboot / Cold boot (happens first thing on Monday morning when I come into 
> the office and turn on my PC).
>  * More free memory (happens when I only have a single window open). I have 
> 16GB of RAM.
>  * Different terminal. I tried CMD prompt and urxvt (Cygwin/X).
>  * Different versions of the Surefire plugin or Maven
>  * Different JDK 8 builds
> Things that affect the bug:
>  * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log
>  * Redirecting all log output to a file using logback-test.xml
>  * Running Surefire with forkCount=0
>  * Running a subset of the tests (-Dtest=...)
>  * Pending Windows updates (I think, not sure about this one).
> Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never 
> seen it with redirecting log output (~ 10 builds). Redirecting sometimes 
> helps but not always.
> One thing which I notice is that one of the tests creates an ActiveMQ broker 
> and uses a shutdown hook to stop it. So I created a small test project which 
> demonstrates that Surefire will sometimes cut off stdout. I think that 
> happens because the main process kills the child after a timeout (correct?).
> So my guess would be that shutdown hooks can mess with the pipeline between 
> the surefire child VM and main Maven process. ActiveMQ might be worse since 
> it stops threads and execution pools (so the output comes slowly with a 
> couple of exceptions sprinkled in when one component loses connection because 
> another is shutting down).
> But now, it gets weird. When the build succeeds, it takes about ~5 minutes to 
> run 1028 tests. The log is 25 MB.
> When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) 
> and the log stops in the middle of a test but is also 25 MB.
> Some of the time discrepancy is probably because writing to a file is faster 
> than printing on a terminal. The strange part is that the log file is about 
> the same size but 30% of the tests haven't run. Most tests log a lot, do I 
> would expect to see a difference of at least a few MB. The Maven part (which 
> contains escape sequences, etc). is just 60 KB.
> Maybe the parent takes some part of the log output as "child terminated".
> I'm running out of ideas what to try next. I think a way to log the 
> communication between parent and child would help. Also the parent should 
> terminate the child and then read stdout until EOF to we can see anything 
> that happens afterwards.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ

[Adolfo Cia (Jira)]

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

Adolfo Cia commented on SUREFIRE-1631:
--

[~tibordigana]

I'm trying the snapshot version you mention in the other ticket, meanwhile, can 
you tell me on which console should I execute that? cmd, powershell, mintty 
(git bash for windows)

> Forked VM terminated without properly saying goodbye with AciveMQ
> -
>
> Key: SUREFIRE-1631
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1631
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20.1, 2.22.0, 3.0.0-M2, 3.0.0-M1
>Reporter: Aaron Digulla
>Assignee: Tibor Digana
>Priority: Major
> Attachments: shurefire-shutdownhook-bug-0.0.1.zip
>
>
> I'm seeing spurious "The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?" messages when running unit tests in 
> a big multi-module project.
> OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of 
> Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191.
> I'm running Maven from the command line using MinTTY (Cygwin).
> Things I tried which have no effect:
>  * Reboot / Cold boot (happens first thing on Monday morning when I come into 
> the office and turn on my PC).
>  * More free memory (happens when I only have a single window open). I have 
> 16GB of RAM.
>  * Different terminal. I tried CMD prompt and urxvt (Cygwin/X).
>  * Different versions of the Surefire plugin or Maven
>  * Different JDK 8 builds
> Things that affect the bug:
>  * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log
>  * Redirecting all log output to a file using logback-test.xml
>  * Running Surefire with forkCount=0
>  * Running a subset of the tests (-Dtest=...)
>  * Pending Windows updates (I think, not sure about this one).
> Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never 
> seen it with redirecting log output (~ 10 builds). Redirecting sometimes 
> helps but not always.
> One thing which I notice is that one of the tests creates an ActiveMQ broker 
> and uses a shutdown hook to stop it. So I created a small test project which 
> demonstrates that Surefire will sometimes cut off stdout. I think that 
> happens because the main process kills the child after a timeout (correct?).
> So my guess would be that shutdown hooks can mess with the pipeline between 
> the surefire child VM and main Maven process. ActiveMQ might be worse since 
> it stops threads and execution pools (so the output comes slowly with a 
> couple of exceptions sprinkled in when one component loses connection because 
> another is shutting down).
> But now, it gets weird. When the build succeeds, it takes about ~5 minutes to 
> run 1028 tests. The log is 25 MB.
> When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) 
> and the log stops in the middle of a test but is also 25 MB.
> Some of the time discrepancy is probably because writing to a file is faster 
> than printing on a terminal. The strange part is that the log file is about 
> the same size but 30% of the tests haven't run. Most tests log a lot, do I 
> would expect to see a difference of at least a few MB. The Maven part (which 
> contains escape sequences, etc). is just 60 KB.
> Maybe the parent takes some part of the log output as "child terminated".
> I'm running out of ideas what to try next. I think a way to log the 
> communication between parent and child would help. Also the parent should 
> terminate the child and then read stdout until EOF to we can see anything 
> that happens afterwards.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SUREFIRE-1713) Another "The forked VM terminated without..." type of issue

[Tibor Digana (Jira)]

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

Tibor Digana commented on SUREFIRE-1713:


[~adolfo.cia]
Today we have to start working on the release of 3.0.0-M4.
So we have to be fast with this issue, otherwise it will be automatically 
postponed.
Let's continue our discussion in SUREFIRE-1631.

> Another "The forked VM terminated without..." type of issue
> ---
>
> Key: SUREFIRE-1713
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1713
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: JUnit 5.x support, Maven Surefire Plugin
>Affects Versions: 2.22.2
> Environment: Windows 10
> Maven 3.6.2
> Maven SureFire 2.22.2
> JUnit5 5.5.2
> Jmockit 1.48
> JDK 1.8.0_191
>Reporter: Adolfo Cia
>Assignee: Tibor Digana
>Priority: Major
> Attachments: surefire-1713.zip
>
>
> Hi,
> I have a recurrent and intermittent error on the same test class of one 
> project from the company I work for.
> It only happens in this test class, so if I annotate with @Disabled, all 
> tests classes run successfully every time.
> Relevant configuration from my pom:
>  
> {code:java}
> 
>   1.8
>   1.48
>   5.5.2
> 
> 
>   
>   
>   org.junit
>   junit-bom
>   ${junit.version}
>   pom
>   import
>   
>   
> 
> 
>   
>   org.jmockit
>   jmockit
>   ${jmockit.version}
>   test
>   
>   
>   org.junit.jupiter
>   junit-jupiter-engine
>   test
>   
>   
>   org.junit.platform
>   junit-platform-launcher
>   test
>   
> 
> 
>   
>   
>   maven-surefire-plugin
>   2.22.2
>   
>   
>   
> -javaagent:${settings.localRepository}/org/jmockit/jmockit/${jmockit.version}/jmockit-${jmockit.version}.jar
>   
>   true
>   
>   
>   
> 
> {code}
> from target/surefire-reports the dump file 
> 2019-11-08T16-58-51_793-jvmRun1.dump has:
>  
>  
> {code:java}
> # Created at 2019-11-08T16:58:56.656
> Killing self fork JVM. Maven process died.
> {code}
> and the output from mvn:
>  
> {code:java}
> [INFO] --- maven-surefire-plugin:2.22.2:test (default-test) @ 
> ltl-java-linehauloperations-ensemble ---
> [INFO]
> [INFO] ---
> [INFO]  T E S T S
> [INFO] ---
> [INFO] Running 
> com.xpo.ltl.linehauloperations.service.ejb.v1.GetImageThumbnailMinuetTest
> ERROR StatusLogger No Log4j 2 configuration file found. Using default 
> configuration (logging only errors to the console), or user programmatically 
> provided configurations. Set system property 'log4j2.debug' to show Log4j 2 
> internal initialization logging. See 
> https://logging.apache.org/log4j/2.x/manual/configuration.html for 
> instructions on how to configure Log4j 2
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time:  12.833 s
> [INFO] Finished at: 2019-11-08T16:58:56-03:00
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on 
> project ltl-java-linehauloperations-ensemble: There are test failures.
> [ERROR]
> [ERROR] Please refer to 
> C:\liberty_development\workspaces\services\ltl-java-linehauloperations-ensemble\target\surefire-reports
>  for the individual test results.
> [ERROR] Please refer to dump files (if any exist) [date].dump, 
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] The forked VM terminated without properly saying goodbye. VM crash or 
> System.exit called?
> [ERROR] Command was cmd.exe /X /C 
> "C:\liberty_development\wlp\java\java\jre\bin\java 
> -javaagent:C:\Users\adolfo.cia\.m2\repository/org/jmockit/jmockit/1.48/jmockit-1.48.jar
>  -jar 
> C:\Users\adolfo.cia\AppData\Local\Temp\surefire6652798836079593172\surefirebooter6928406549506356470.jar
>  C:\Users\adolfo.cia\AppData\Local\Temp\surefire6652798836079593172 
> 2019-11-08T16-58-51_793-jvmRun1 surefire4400063069909447928tmp 
> surefire_03777119448075675073tmp"
> [ERROR] Error occurred in starting fork, 

[jira] [Commented] (SUREFIRE-1713) Another "The forked VM terminated without..." type of issue

[Adolfo Cia (Jira)]

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

Adolfo Cia commented on SUREFIRE-1713:
--

[~tibordigana]

Thanks for the reply.

I'll try that SNAPSHOT version, and let you know.

Also, I'll continue reporting in the other ticket you mention.

 

Thanks

> Another "The forked VM terminated without..." type of issue
> ---
>
> Key: SUREFIRE-1713
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1713
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: JUnit 5.x support, Maven Surefire Plugin
>Affects Versions: 2.22.2
> Environment: Windows 10
> Maven 3.6.2
> Maven SureFire 2.22.2
> JUnit5 5.5.2
> Jmockit 1.48
> JDK 1.8.0_191
>Reporter: Adolfo Cia
>Assignee: Tibor Digana
>Priority: Major
> Attachments: surefire-1713.zip
>
>
> Hi,
> I have a recurrent and intermittent error on the same test class of one 
> project from the company I work for.
> It only happens in this test class, so if I annotate with @Disabled, all 
> tests classes run successfully every time.
> Relevant configuration from my pom:
>  
> {code:java}
> 
>   1.8
>   1.48
>   5.5.2
> 
> 
>   
>   
>   org.junit
>   junit-bom
>   ${junit.version}
>   pom
>   import
>   
>   
> 
> 
>   
>   org.jmockit
>   jmockit
>   ${jmockit.version}
>   test
>   
>   
>   org.junit.jupiter
>   junit-jupiter-engine
>   test
>   
>   
>   org.junit.platform
>   junit-platform-launcher
>   test
>   
> 
> 
>   
>   
>   maven-surefire-plugin
>   2.22.2
>   
>   
>   
> -javaagent:${settings.localRepository}/org/jmockit/jmockit/${jmockit.version}/jmockit-${jmockit.version}.jar
>   
>   true
>   
>   
>   
> 
> {code}
> from target/surefire-reports the dump file 
> 2019-11-08T16-58-51_793-jvmRun1.dump has:
>  
>  
> {code:java}
> # Created at 2019-11-08T16:58:56.656
> Killing self fork JVM. Maven process died.
> {code}
> and the output from mvn:
>  
> {code:java}
> [INFO] --- maven-surefire-plugin:2.22.2:test (default-test) @ 
> ltl-java-linehauloperations-ensemble ---
> [INFO]
> [INFO] ---
> [INFO]  T E S T S
> [INFO] ---
> [INFO] Running 
> com.xpo.ltl.linehauloperations.service.ejb.v1.GetImageThumbnailMinuetTest
> ERROR StatusLogger No Log4j 2 configuration file found. Using default 
> configuration (logging only errors to the console), or user programmatically 
> provided configurations. Set system property 'log4j2.debug' to show Log4j 2 
> internal initialization logging. See 
> https://logging.apache.org/log4j/2.x/manual/configuration.html for 
> instructions on how to configure Log4j 2
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time:  12.833 s
> [INFO] Finished at: 2019-11-08T16:58:56-03:00
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on 
> project ltl-java-linehauloperations-ensemble: There are test failures.
> [ERROR]
> [ERROR] Please refer to 
> C:\liberty_development\workspaces\services\ltl-java-linehauloperations-ensemble\target\surefire-reports
>  for the individual test results.
> [ERROR] Please refer to dump files (if any exist) [date].dump, 
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] The forked VM terminated without properly saying goodbye. VM crash or 
> System.exit called?
> [ERROR] Command was cmd.exe /X /C 
> "C:\liberty_development\wlp\java\java\jre\bin\java 
> -javaagent:C:\Users\adolfo.cia\.m2\repository/org/jmockit/jmockit/1.48/jmockit-1.48.jar
>  -jar 
> C:\Users\adolfo.cia\AppData\Local\Temp\surefire6652798836079593172\surefirebooter6928406549506356470.jar
>  C:\Users\adolfo.cia\AppData\Local\Temp\surefire6652798836079593172 
> 2019-11-08T16-58-51_793-jvmRun1 surefire4400063069909447928tmp 
> surefire_03777119448075675073tmp"
> [ERROR] Error occurred in starting fork, check output in log
> [ERROR] Process Exit Code: 

[jira] [Closed] (SUREFIRE-1715) Platform support for 'maven-surefire-plugin' on PowerPC64LE

[Michael Osipov (Jira)]

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

Michael Osipov closed SUREFIRE-1715.

Resolution: Invalid

This is not a Surefire issue. Inquire with upstream project.

> Platform support for 'maven-surefire-plugin' on PowerPC64LE
> ---
>
> Key: SUREFIRE-1715
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1715
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.22.0
> Environment: PPC64LE
>Reporter: Sarvesh Tamba
>Priority: Blocker
> Attachments: maven-surefire-plugin_error.txt
>
>
> I am trying to build/install keycloak/keycloak on PPC64LE architecture with 
> Red Hat Enterprise Linux 7, using the commands mentioned here - 
> https://github.com/keycloak/keycloak/blob/master/docs/building.md
> I have updated the `mvn-golang-wrapper` with workaround as described in 
> "https://github.com/raydac/mvn-golang/issues/70;
> However I am seeing the following issues as below:-
> ```
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.22.0:test (default-test) on 
> project integration-arquillian-tests-base: There are test failures.
> ```
> Also seeing the following error in the log (not sure if the two are related)
> ```
> /root/keycloak/keycloak/testsuite/integration-arquillian/tests/base/target/drone/1c947d57fce2f21ce0b43fe2ed7cd361/phantomjs-2.1.1-linux-x86_64/bin/phantomjs:
>  cannot execute binary file
> ```
> Attached is the detailed log output.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (SUREFIRE-1715) Platform support for 'maven-surefire-plugin' on PowerPC64LE

[Sarvesh Tamba (Jira)]

Sarvesh Tamba created SUREFIRE-1715:
---

 Summary: Platform support for 'maven-surefire-plugin' on 
PowerPC64LE
 Key: SUREFIRE-1715
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1715
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Surefire Plugin
Affects Versions: 2.22.0
 Environment: PPC64LE
Reporter: Sarvesh Tamba
 Attachments: maven-surefire-plugin_error.txt

I am trying to build/install keycloak/keycloak on PPC64LE architecture with Red 
Hat Enterprise Linux 7, using the commands mentioned here - 
https://github.com/keycloak/keycloak/blob/master/docs/building.md
I have updated the `mvn-golang-wrapper` with workaround as described in 
"https://github.com/raydac/mvn-golang/issues/70;

However I am seeing the following issues as below:-
```
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-surefire-plugin:2.22.0:test (default-test) on 
project integration-arquillian-tests-base: There are test failures.
```

Also seeing the following error in the log (not sure if the two are related)
```
/root/keycloak/keycloak/testsuite/integration-arquillian/tests/base/target/drone/1c947d57fce2f21ce0b43fe2ed7cd361/phantomjs-2.1.1-linux-x86_64/bin/phantomjs:
 cannot execute binary file
```

Attached is the detailed log output.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-wagon] hboutemy edited a comment on issue #60: [WAGON-574] advertise jsoup license for shaded jar

[GitBox]

hboutemy edited a comment on issue #60: [WAGON-574] advertise jsoup license for 
shaded jar
URL: https://github.com/apache/maven-wagon/pull/60#issuecomment-552397188
 
 
   @michael-o 
   
   > First of all, Maven Core does not rely on that. Can you search for method 
in our code case?!
   
   sure, core does not, but core provides Wagon implementation to plugins: the 
issue is more subtle, people will have features that may not work with newer 
Maven versions
   
   > The implementation is highly coupled to a 10+ y/o Apache HTTPd mod_userdir 
output.
   
   you mean that it does not work for current central directory listing, like 
https://repo.maven.apache.org/maven2/org/apache/maven/wagon/ ? or it does not 
work for classical repository manager directory listing, like 
https://repository.apache.org/content/groups/snapshots/org/apache/maven/wagon/wagon/
 ?
   
   for the record, pointer to code 
https://maven.apache.org/wagon-archives/wagon-3.3.3/wagon-providers/wagon-http-shared/xref/org/apache/maven/wagon/shared/http/HtmlFileListParser.html
   
   > It was a misconception from the beginning.
   
   it's usual for repository managers to provide directory listing, it's a 
useful idea
   
   Now:
   1. once we figure out if the feature is really working or not, we could 
perhaps avoid this jsoup dependency: html we're looking for is probably not 
that complex
   2. the MIT license in artifact's pom.xml with comment looks to me a 
reasonable quick first step


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [maven-wagon] hboutemy commented on issue #60: [WAGON-574] advertise jsoup license for shaded jar

[GitBox]

hboutemy commented on issue #60: [WAGON-574] advertise jsoup license for shaded 
jar
URL: https://github.com/apache/maven-wagon/pull/60#issuecomment-552397188
 
 
   @michael-o 
   
   > First of all, Maven Core does not rely on that. Can you search for method 
in our code case?!
   
   sure, core does not, but core provides Wagon implementation to plugins: the 
issue is more subtle, people will have features that may not work with newer 
Maven versions
   
   > The implementation is highly coupled to a 10+ y/o Apache HTTPd mod_userdir 
output.
   
   you mean that it does not work for current central directory listing, like 
https://repo.maven.apache.org/maven2/org/apache/maven/wagon/ ? or it does not 
work for classical repository manager directory listing, like 
https://repository.apache.org/content/groups/snapshots/org/apache/maven/wagon/wagon/
 ?
   
   > It was a misconception from the beginning.
   
   it's usual for repository managers to provide directory listing, it's a 
useful idea
   
   Now:
   1. once we figure out if the feature is really working or not, we could 
perhaps avoid this jsoup dependency: html we're looking for is probably not 
that complex
   2. the MIT license in artifact's pom.xml with comment looks to me a 
reasonable quick first step


This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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] [Updated] (WAGON-574) improve license management when distributing Wagon shaded binary

[Herve Boutemy (Jira)]

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

Herve Boutemy updated WAGON-574:

Description: 
as discussed during Wagon 3.3.4 release vote 
https://lists.apache.org/thread.html/7526295d1eb080d8d573cfcc2fe4c006c0d948287da7163cc85eadff@%3Cdev.maven.apache.org%3E
 , 
wagon-http-3.3.4-shaded.jar includes jsoup, which is MIT licensed
this should be advertised (since wagon 2.5...)

  was:
as discussed during Wagon 3.3.4 release vote 
https://lists.apache.org/thread.html/7526295d1eb080d8d573cfcc2fe4c006c0d948287da7163cc85eadff@%3Cdev.maven.apache.org%3E
 , 
wagon-http-3.3.4-shaded.jar includes jsoup, which is MIT licensed
this should be advertised


> improve license management when distributing Wagon shaded binary
> 
>
> Key: WAGON-574
> URL: https://issues.apache.org/jira/browse/WAGON-574
> Project: Maven Wagon
>  Issue Type: New Feature
>  Components: wagon-http
>Affects Versions: 2.5, 2.6, 2.7, 2.8, 2.9, 2.10, 2.11, 2.12, 3.0.0, 3.1.0, 
> 3.2.0, 3.3.0, 3.3.1, 3.3.2, 3.3.3, 3.3.4
>Reporter: Herve Boutemy
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> as discussed during Wagon 3.3.4 release vote 
> https://lists.apache.org/thread.html/7526295d1eb080d8d573cfcc2fe4c006c0d948287da7163cc85eadff@%3Cdev.maven.apache.org%3E
>  , 
> wagon-http-3.3.4-shaded.jar includes jsoup, which is MIT licensed
> this should be advertised (since wagon 2.5...)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (WAGON-574) improve license management when distributing Wagon shaded binary

[Herve Boutemy (Jira)]

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

Herve Boutemy updated WAGON-574:

Affects Version/s: 2.6
   2.7
   2.8
   2.9
   2.10
   2.11
   2.12
   3.1.0
   3.2.0
   3.3.0
   3.3.1
   3.3.2
   3.3.3

> improve license management when distributing Wagon shaded binary
> 
>
> Key: WAGON-574
> URL: https://issues.apache.org/jira/browse/WAGON-574
> Project: Maven Wagon
>  Issue Type: New Feature
>  Components: wagon-http
>Affects Versions: 2.5, 2.6, 2.7, 2.8, 2.9, 2.10, 2.11, 2.12, 3.0.0, 3.1.0, 
> 3.2.0, 3.3.0, 3.3.1, 3.3.2, 3.3.3, 3.3.4
>Reporter: Herve Boutemy
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> as discussed during Wagon 3.3.4 release vote 
> https://lists.apache.org/thread.html/7526295d1eb080d8d573cfcc2fe4c006c0d948287da7163cc85eadff@%3Cdev.maven.apache.org%3E
>  , 
> wagon-http-3.3.4-shaded.jar includes jsoup, which is MIT licensed
> this should be advertised



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (WAGON-574) improve license management when distributing Wagon shaded binary

[Herve Boutemy (Jira)]

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

Herve Boutemy updated WAGON-574:

Summary: improve license management when distributing Wagon shaded binary  
(was: improve license management when distributing Wagon binaries)

> improve license management when distributing Wagon shaded binary
> 
>
> Key: WAGON-574
> URL: https://issues.apache.org/jira/browse/WAGON-574
> Project: Maven Wagon
>  Issue Type: New Feature
>  Components: wagon-http
>Affects Versions: 2.5, 3.0.0, 3.3.4
>Reporter: Herve Boutemy
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> as discussed during Wagon 3.3.4 release vote 
> https://lists.apache.org/thread.html/7526295d1eb080d8d573cfcc2fe4c006c0d948287da7163cc85eadff@%3Cdev.maven.apache.org%3E
>  , 
> wagon-http-3.3.4-shaded.jar includes jsoup, which is MIT licensed
> this should be advertised



--
This message was sent by Atlassian Jira
(v8.3.4#803005)