Guten Tag Martin Grigorov, am Montag, 30. September 2019 um 15:25 schrieben Sie:
> It will be good to find what in your environment causes the problem. > Maybe it is some environment variable, or your system locale, or something > else. My Windows is pretty standard, I'm not even running AV-software, including on-board Defender. That has been disabled using group policies. The only difference to others is my German locale most likely. Looking at Process Monitor, Wicket seems to search for localized files for all test including HTML and text, never finds those for de_DE and all those other tests succeed anyway. Doesn't look like the actual problem to me. > For me this test passes. It must pass at Maxim's machine as well because he > built the release. > Could someone else with Windows run the test and report ? I've found an additional way to make the build succeed WITHOUT ignoring the formerly mentioned test: Switching the option to reuse forked JMV by surefire to "false" in pom.xml. > <reuseForks>false</reuseForks> Switching between true and false make the build failing vs. succeeding. What's additionally interesting is that in case the build fails, executing the command line from the error message manually in some other cmd.exe seems to succeed: > cmd.exe /X /C ""C:\Program Files\Java\jdk-8\bin\java.exe" -Xmx1024m -jar > C:\Users\tschoening\AppData\Local\Temp\surefire3649246175279820451\surefirebooter4577796592449395223.jar > C:\Users\tschoening\AppData\Local\Temp\surefire3649246175279820451 > 2019-09-30T16-38-42_368-jvmRun1 surefire9181599006974311426tmp > surefire_07065828248506771667tmp"" > 3,1,windows-1252,[org.apache.wicket.page.PageAccessSynchronizer] DEBUG - > 'main' released lock to page with id '1'\0D\0A > 3,1,windows-1252,[org.apache.wicket.page.PageAccessSynchronizer] DEBUG - > 'main' notifying blocked threads\0D\0A > 3,1,windows-1252,[org.apache.wicket.protocol.http.servlet.ServletWebRequest] > DEBUG - Calculating context relative path from: context path '/context'\2C > filterPrefix 'servlet/'\2C uri '/context/servlet/'\0D\0A > 6,1,org.wicketstuff.jamon.request.cycle.JamonMonitoredRequestCycleTest,shouldCreateTwoMonitorsForPagesThatAreNavigatedToTwice(org.wicketstuff.jamon.request.cycle.JamonMonitoredRequestCycleTest),null,null,null > 2,1,org.apache.maven.surefire.junit4.JUnit4Provider,org.wicketstuff.jamon.request.cycle.JamonMonitoredRequestCycleTest,null,null,null > Z,0,BYE! Which very much reads like a proper "goodbye" like mentioned in the error message at the beginning. My feeling is that for some reason surefire is not able to properly recognize that goodbye in some combinations of tests anymore if those were run within the same JVM. > If there is JVM crash then there must be a hs_errPID.txt file in the Maven > process working folder. It will give you more information what went wrong. I don't find such file, neither searching the file system, nor looking at the logs of Process Monitor during running the build. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...........05151- 9468- 55 Fax...............05151- 9468- 88 Mobil..............0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
