Is it possible it is caused by Java version? Travis uses java version "1.8.0_151" Java(TM) SE Runtime Environment (build 1.8.0_151-b12) Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
I locally using java version "1.8.0_201" Java(TM) SE Runtime Environment (build 1.8.0_201-b09) Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, mixed mode) On Mon, 30 Sep 2019 at 22:04, Thorsten Schöning <tschoen...@am-soft.de> wrote: > 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 > > -- WBR Maxim aka solomax
