It's up to you, but I can imagine this is going to be a painful place to debug. We've had plenty of issues with the ICU library in the past and it's never fun.
I'd recommend starting with one of the issues previously mentioned, at least to get your feet wet with Daffoil development. I'll create a bug to track the issues you found and we'll move them to scala-debug until it's sorted out. If you can think of any thing that might be helpful in reproducing this issue, feel free to email or add it to the bug. - Steve On 05/24/2018 12:12 PM, Russ Williams wrote: > Cheers! Yeah, I’m not familiar with SBT, so that’ll come in handy. > > If it were a thread issue, I’d expect the results to be more random - the > failures have been 100% consistent, in the same tests, with the same values > returned. Could just be that I’m lucky. > > I’ll also install Eclipse - have used it a lot, but not on my home machine - > and see if I can debug into the test to see why the results are coming out > the way they are. > > Given that this is (currently) only affecting me, shall I ignore these > specific tests and go ahead with the branch/bug fixes as discussed yesterday? > >> On 24 May 2018, at 14:06, Steve Lawrence <[email protected]> wrote: >> >> That's a good thought. If you're unfamiliar with sbt, to run a single >> test you can do something like this: >> >> $ sbt "testOnly org.apache.daffodil.IBMTestsThatPass -- >> --tests=test_simple_type_properties_text_calendar_13_01" >> >> - Steve >> >> On 05/24/2018 08:48 AM, Mike Beckerle wrote: >>> Russ, >>> >>> The main thing I hate about the java time libraries (old school Date, Time, >>> DateTime) is that they are stateful, when run en-masse, our tests are >>> multi-threaded. >>> >>> Have you tried running these tests one at a time in isolation? I am >>> wondering if someplace we are sharing state accidently? >>> >>> ...mikeb >>> >>> ________________________________ >>> From: Russ Williams <[email protected]> >>> Sent: Thursday, May 24, 2018 4:47:52 AM >>> To: [email protected] >>> Subject: Test failures in master >>> >>> Hi! >>> >>> Testing the build process with a clone of the current master branch, I’m >>> getting five test failures related to calendar handling for day-of-week and >>> week-of-year. >>> >>> One in daffodil-test-ibm1/test: >>> [error] Test >>> org.apache.daffodil.IBMTestsThatPass.test_simple_type_properties_text_calendar_13_01 >>> failed: java.lang.Exception: >>> [error] Comparison failed. >>> [error] Expected >>> [error] >>> <myDateTime>2010-12-27T04:05:06.000000+00:00</myDateTime> >>> [error] Actual >>> [error] >>> <myDateTime>2010-12-20T04:05:06.000000+00:00</myDateTime> >>> >>> >>> Four in daffodil-test/test: >>> [error] Test >>> org.apache.daffodil.section05.simple_types.TestSimpleTypes.test_dateCalendarDaysInFirstWeek3 >>> failed: java.lang.Exception: >>> [error] Comparison failed. >>> [error] Expected >>> [error] <date17>2012-01-01+00:00</date17> >>> [error] Actual >>> [error] <date17>2012-12-23+00:00</date17> >>> >>> [error] Test >>> org.apache.daffodil.section05.simple_types.TestSimpleTypes.test_dateCalendarDaysInFirstWeek5 >>> failed: java.lang.Exception: >>> [error] Comparison failed. >>> [error] Expected >>> [error] <date20>2013-02-24+00:00</date20> >>> [error] Actual >>> [error] <date20>2013-02-10+00:00</date20> >>> >>> [error] Test >>> org.apache.daffodil.section05.simple_types.TestSimpleTypes.test_dateCalendarFirstDayOfWeek03 >>> failed: java.lang.Exception: >>> [error] Comparison failed. >>> [error] Expected >>> [error] <date06>2013-02-03+00:00</date06> >>> [error] Actual >>> [error] <date06>2013-02-02+00:00</date06> >>> >>> [error] Test >>> org.apache.daffodil.section05.simple_types.TestSimpleTypes.test_dateCalendarFirstDayOfWeek04 >>> failed: java.lang.Exception: >>> [error] Comparison failed. >>> [error] Expected >>> [error] <date06>2013-02-04+00:00</date06> >>> [error] Actual >>> [error] <date06>2013-02-03+00:00</date06> >>> >>> >>> The dateCalendarDaysInFirstWeek3 failure is particularly bad since it’s >>> looking for “week 1 of 2012”, which should start on 2012-01-01, but it’s >>> getting a date in *December* 2012. >>> >>> >>> Every other test passes cleanly. >>> I’ve got the same result on my Mac (macOS Sierra/10.12.6, Oracle Java >>> 1.8.0_51-b16) and a Linux box (Ubuntu 16.04 LTS, Oracle Java 1.8.0_111-b14). >>> Setting -Duser.timezone in JAVA_OPTS doesn’t make any difference. >>> I haven’t been able to test with OpenJDK yet. >>> >>> Cheers, >>> — >>> Russ >>> >> >
