webprotege icon indicating copy to clipboard operation
webprotege copied to clipboard

Build failure due to test failure (TimeUtil_TestCase)

Open hammar opened this issue 9 years ago • 8 comments

Hi,

Attempting to compile per instructions:

mvn -Pdeployment -Dapplication.host=wp.ecare.infoeng.se package

produces:

[INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 4:40.827s [INFO] Finished at: Tue Feb 02 16:43:48 CET 2016 [INFO] Final Memory: 54M/340M [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.16:test (default-test) on project webprotege: There are test failures. [ERROR] [ERROR] Please refer to /home/karl/webprotege/target/surefire-reports for the individual test results. [ERROR] -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException

Some more details a bit earlier in the output stream:

`Running edu.stanford.bmir.protege.web.shared.TimeUtil_TestCase Tests run: 11, Failures: 6, Errors: 0, Skipped: 0, Time elapsed: 0.02 sec <<< FAILURE! - in edu.stanford.bmir.protege.web.shared.TimeUtil_TestCase shouldReturnDateRendering(edu.stanford.bmir.protege.web.shared.TimeUtil_TestCase) Time elapsed: 0.005 sec <<< FAILURE! java.lang.AssertionError: Expected: is "1st September 2011" but: was "2nd September 2011" at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20) at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:8) at edu.stanford.bmir.protege.web.shared.TimeUtil_TestCase.shouldReturnDateRendering(TimeUtil_TestCase.java:71)

shouldReturnDateRendering2(edu.stanford.bmir.protege.web.shared.TimeUtil_TestCase) Time elapsed: 0 sec <<< FAILURE! java.lang.AssertionError: Expected: is "2nd September 2011" but: was "3rd September 2011" at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20) at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:8) at edu.stanford.bmir.protege.web.shared.TimeUtil_TestCase.shouldReturnDateRendering2(TimeUtil_TestCase.java:77)

shouldReturnDateRendering3(edu.stanford.bmir.protege.web.shared.TimeUtil_TestCase) Time elapsed: 0 sec <<< FAILURE! java.lang.AssertionError: Expected: is "3rd September 2011" but: was "4th September 2011" at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20) at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:8) at edu.stanford.bmir.protege.web.shared.TimeUtil_TestCase.shouldReturnDateRendering3(TimeUtil_TestCase.java:83)

shouldReturnDateRendering4(edu.stanford.bmir.protege.web.shared.TimeUtil_TestCase) Time elapsed: 0.001 sec <<< FAILURE! java.lang.AssertionError: Expected: is "4th September 2011" but: was "5th September 2011" at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20) at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:8) at edu.stanford.bmir.protege.web.shared.TimeUtil_TestCase.shouldReturnDateRendering4(TimeUtil_TestCase.java:89)

shouldReturnDateRendering21(edu.stanford.bmir.protege.web.shared.TimeUtil_TestCase) Time elapsed: 0.001 sec <<< FAILURE! java.lang.AssertionError: Expected: is "21st September 2011" but: was "22nd September 2011" at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20) at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:8) at edu.stanford.bmir.protege.web.shared.TimeUtil_TestCase.shouldReturnDateRendering21(TimeUtil_TestCase.java:95)

shouldReturnDateRendering30(edu.stanford.bmir.protege.web.shared.TimeUtil_TestCase) Time elapsed: 0 sec <<< FAILURE! java.lang.AssertionError: Expected: is "30th September 2011" but: was "1st October 2011" at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20) at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:8) at edu.stanford.bmir.protege.web.shared.TimeUtil_TestCase.shouldReturnDateRendering30(TimeUtil_TestCase.java:101) `

I've never had this happen before. On the other hand I've never compiled Webprotégé on this new machine. It's running Ubuntu Server 14.04 LTS and Oracle Java 8.

karl@ecare:~/webprotege$ mvn -version Apache Maven 3.0.5 Maven home: /usr/share/maven Java version: 1.8.0_72, vendor: Oracle Corporation Java home: /usr/lib/jvm/java-8-oracle/jre Default locale: sv_SE, platform encoding: UTF-8 OS name: "linux", version: "3.19.0-49-generic", arch: "amd64", family: "unix"

hammar avatar Feb 02 '16 15:02 hammar

Confirmed the same thing happens on another machine. Same software configuration, different hardware. Possibly a locale or timezone issue? But I'm too busy at the moment to debug deeper. Adding " -DskipTests" to maven command line skips the tests but builds correctly. I'm hoping I don't run into problems later on though.. :)

hammar avatar Feb 02 '16 18:02 hammar

Ran into the same problem. Skipping the tests for now, I'll post back if I manage to find what causes this.

iFrag avatar Feb 25 '16 07:02 iFrag

"Me too". This is certainly a timezone issue. I am in Canberra, which (right now) is UTC + 10 hours, far enough way from Stanford time ...

E.g., the test shouldReturnDateRendering() computes a rendering of the constant THU_SEPTEMBER_FIRST_2011, which is defined to have the value 1314917789000l.

For me, the output of (Mac) command date -r 1314917789 is:

Fri  2 Sep 2011 08:56:29 AEST

The TimeUtil class generates formatted results based on the local timezone, so in my case, that is 2nd September 2011, and that does not match the expected value of 1st September 2011.

rwalkerands avatar Jul 04 '16 05:07 rwalkerands

Got the same error. Not sure if this is the actual source of the error, but I starting working with WebProtege in England. I made some modifications in Norway (+1 wrt UK) and the Time-related test failed. I changed the time in my laptop back to UK time, re-run the built, and everything works as before. There may be a log somewhere with the original (first check-out or first built, not sure) timezone.

Ernesto

ernestojimenezruiz avatar Oct 17 '16 12:10 ernestojimenezruiz

Same result. Using Berlin time the tests fails, but changing the Time Zone to London time works flawlessly.

ismaelrh avatar Jun 26 '17 08:06 ismaelrh

I could try to resolve this if either solution is acceptable.

  1. I've changed timestamps to get them from the java 8 library, instead of using the current longs.

+import java.sql.Timestamp; +import java.time.LocalDate;

+import java.sql.Timestamp;
+import java.time.LocalDate;

 -   public static final long THU_SEPTEMBER_FIRST_2011 = 1314917789000l;
+    public static final long THU_SEPTEMBER_FIRST_2011 = Timestamp.valueOf(LocalDate.of(2011, 9, 1).atStartOfDay()).getTime();
 
-    public static final long THU_SEPTEMBER_TWENTY_FIRST_2011 = 1316645789000l;
+    public static final long THU_SEPTEMBER_TWENTY_FIRST_2011 = Timestamp.valueOf(LocalDate.of(2011, 9, 21).atStartOfDay()).getTime();
 
-    public static final long THU_SEPTEMBER_THIRTIETH_2011 = 1317423389000l;
+    public static final long THU_SEPTEMBER_THIRTIETH_2011 = Timestamp.valueOf(LocalDate.of(2011, 9, 30).atStartOfDay()).getTime();
  1. I changed TimeZone.setDefault(...); for the tests containing dates, which also made the test pass. The constants could also probably be renamed to be clear that the longs are for a date within a specific timezone.

OyvindLGjesdal avatar May 24 '20 08:05 OyvindLGjesdal

Came across the same issue today building the latest version

jgongil avatar Aug 05 '20 09:08 jgongil

This issue still occor

zjmwqx avatar Mar 02 '22 11:03 zjmwqx