Hi Gary, On Wed, Jul 1, 2020 at 4:26 PM Gary Gregory <garydgreg...@gmail.com> wrote:
> Have you tried the more recent version of the Maven surefire plugin? > I'm using Maven 3.6.3. I changed to the latest stable version of Maven surefire plugin (3.0.0-M5), and its producing the same build error. I was using Maven surefire plugin version 2.22.2 earlier. I've also debugged along the lines of latest comment by Bernd, with regards to available RAM on my Windows dev workstation. I've total RAM of 8 GB. Originally, I was working with default settings for -Xmx on MAVEN_OPTS environment variable (which I guess has value 512 MB). I changed that to 3 GB, and my workstation's total RAM usage is well below 100% (it hovers around 70%) during my entire run of command 'mvn clean test', and I get same test case crash. I've also found related information at, https://maven.apache.org/surefire/maven-surefire-plugin/examples/shutdown.html. At the bottom of this link, following is mentioned, <quote> Crashed forked JVM caused listing the crashed test(s) After the JVM exited abruptly, the console lists the message Crashed tests: with a list of crashed tests if the entire test-set has not been yet completed. This happens if a test exited, killed JVM or a segmentation fault crashed JVM. In such cases you may be interested in dump files generated in reports directory, see FAQ. </quote> When I read the FAQ (the last word within above 'quote'), and according to that information, I see following hint in the file 2020-07-02T11-58-54_573.dumpstream (there are no other dump files created during my run of 'mvn clean test'), *Boot Manifest-JAR contains absolute paths in classpath 'F:\eclipseWorkspaces\haldiram_backend_sprint-19_sts\haldiram-backend\haldiram-restapis\target\test-classes'* *Hint: <argLine>-Djdk.net.URLClassPath.disableClassPathURLCheck=true</argLine>* According to above referred hint, I then ran the following command, mvn clean test -Djdk.net.URLClassPath.disableClassPathURLCheck=true But this produced the same error (although, this time the mvn test process crashed on a different test file than what I experienced originally). Any thoughts, what I could do next on my Windows dev workstation to solve the problem I've mentioned in this thread? -- Regards, Mukul Gandhi
