Details
-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
1.1.7
-
None
-
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
Maven home: /Users/huxi/.sdkman/candidates/maven/current
Java version: 1.8.0_92, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.11.5", arch: "x86_64", family: "mac"Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00) Maven home: /Users/huxi/.sdkman/candidates/maven/current Java version: 1.8.0_92, vendor: Oracle Corporation Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "10.11.5", arch: "x86_64", family: "mac"
Description
Trying to perform a mvn clean install on revision 03e26684d43066d53dbf926e060a73d43bee77fd causes the following tests to fail:
Failed tests: TimeBasedRollingWithArchiveRemoval_Test.checkThatSmallTotalSizeCapLeavesAtLeastOneArhcive:191->checkFileCount:484 expected:<1> but was:<0> RollingCalendarTest.testCollisionFreenes:148->checkCollisionFreeness:158 RollingCalendarTest.testPeriodicity:63 expected:<TOP_OF_WEEK> but was:<TOP_OF_MONTH> Tests run: 532, Failures: 3, Errors: 0, Skipped: 7
The System.out.println in computePeriodicityType of RollingCalendar is printing the following things:
RollingCalendarTest.testPeriodicity
Type = TOP_OF_WEEK, r0 = 1970-01, r1 = 1970-01 Type = TOP_OF_MONTH, r0 = 1970-01, r1 = 1970-05 java.lang.AssertionError: Expected :TOP_OF_WEEK Actual :TOP_OF_MONTH
The failing code looks like this:
{ RollingCalendar rc = new RollingCalendar("yyyy-ww"); assertEquals(PeriodicityType.TOP_OF_WEEK, rc.getPeriodicityType()); }
RollingCalendarTest.testCollisionFreenes
java.lang.AssertionError at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertFalse(Assert.java:68) at org.junit.Assert.assertFalse(Assert.java:79) at ch.qos.logback.core.rolling.helper.RollingCalendarTest.checkCollisionFreeness(RollingCalendarTest.java:158) at ch.qos.logback.core.rolling.helper.RollingCalendarTest.testCollisionFreenes(RollingCalendarTest.java:148)
The line in question is this:
checkCollisionFreeness("yyyy-WW", false);
TimeBasedRollingWithArchiveRemoval_Test.checkThatSmallTotalSizeCapLeavesAtLeastOneArhcive
Type = TOP_OF_MILLISECOND, r0 = 1970-01-01, r1 = 1970-01-01 Type = TOP_OF_SECOND, r0 = 1970-01-01, r1 = 1970-01-01 Type = TOP_OF_MINUTE, r0 = 1970-01-01, r1 = 1970-01-01 Type = TOP_OF_HOUR, r0 = 1970-01-01, r1 = 1970-01-01 Type = TOP_OF_DAY, r0 = 1970-01-01, r1 = 1970-01-02 cp.periodDurationInMillis=86400000, tickDuration=:400000, runLength=648 Sat Mar 26 13:13:45 CET 2016 13:18:47,353 |-INFO in c.q.l.core.rolling.TimeBasedRollingPolicy@1159114532 - No compression will be used 13:18:47,353 |-INFO in c.q.l.core.rolling.TimeBasedRollingPolicy@1159114532 - Will use the pattern target/test-output/1647000378/clean-%d{yyyy-MM-dd}.txt for the active file 13:18:47,353 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - The date pattern is 'yyyy-MM-dd' from file name pattern 'target/test-output/1647000378/clean-%d{yyyy-MM-dd}.txt'. 13:18:47,353 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - Roll-over at midnight. 13:18:47,354 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - Setting initial period to Wed Mar 23 13:07:05 CET 2016 13:18:47,354 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[null] - Active log file name: target/test-output/1647000378/clean-2016-03-23.txt 13:18:47,354 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[null] - File property is set to [null] 13:18:47,354 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - Elapsed period: Wed Mar 23 13:07:05 CET 2016 13:18:47,355 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - first clean up after appender initialization 13:18:47,355 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - Multiple periods, i.e. 31 periods, seem to have elapsed. This is expected at application start. 13:18:47,356 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - Deleting [target/test-output/1647000378/clean-2016-03-24.txt] of size 76 Bytes 13:18:47,356 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - Deleting [target/test-output/1647000378/clean-2016-03-23.txt] of size 7 KB 13:18:47,356 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - Removed 7 KB of files 13:18:47,358 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - Elapsed period: Thu Mar 24 00:00:25 CET 2016 13:18:47,359 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - Removed 0 Bytes of files 13:18:47,361 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - Elapsed period: Fri Mar 25 00:00:25 CET 2016 13:18:47,362 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - Deleting [target/test-output/1647000378/clean-2016-03-26.txt] of size 75 Bytes 13:18:47,362 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - Deleting [target/test-output/1647000378/clean-2016-03-25.txt] of size 15 KB 13:18:47,362 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - Removed 15 KB of files java.lang.AssertionError: Expected :1 Actual :0 at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at ch.qos.logback.core.rolling.TimeBasedRollingWithArchiveRemoval_Test.checkFileCount(TimeBasedRollingWithArchiveRemoval_Test.java:484) at ch.qos.logback.core.rolling.TimeBasedRollingWithArchiveRemoval_Test.checkThatSmallTotalSizeCapLeavesAtLeastOneArhcive(TimeBasedRollingWithArchiveRemoval_Test.java:191)
Stuff I already tried:
- changed TimeZone in RollingCalendar from GMT to UTC
- changed Locale of GregorianCalendar in computePeriodicityType from Locale.getDefault() to Locale.ENGLISH and Locale.US.
No change in behavior.
Given that Logback Travis CI is building fine with Java 1.7.0_80 but I'm using Java 1.8.0_92, I strongly suspect that the failures are actually caused by an incompatibility introduced in Java 8. I can't personally check against Java 7 anymore because Oracle.
You could try this out by adding the following to your .travis.yml file:
jdk: - oraclejdk8 - oraclejdk7 - openjdk7 - openjdk6
(The above worked about a year ago. It's possible that something changed at Travis in the meantime.)
Hope this helps.