Gradle Build Failed

Is it normal?

I built it with jdk1.8.0_131 and jre1.8.0_141 on Windows 10 following this post

1 Like

Hi @chiwai,

No that is not “normal” :slight_smile:

The continuous integration build is done on Linux, and my personal experience is on a Mac - which are both building fine.

I wonder, do any other Windows 10 users have any input on this?

EDIT: This is non-critical, and won’t hurt results btw. Though we don’t want to see this, those two tests aren’t in critical functional places.

I’m on Windows 10, and based on my execution results there are a couple of different non-critical causes.

The first is to do with how file deletions are handled by the JVM in Windows. The HTMNetworkTests directory is being deleted at the end of some tests and then created again by another test, but in reality the previous one hasn’t completed yet and there is still an open handle, this causes IOExceptions. You’ll notice that if you run the failed test(s) in isolation, they will pass.

The issue in testMain is that \n is used as a line separator when streaming out, then the test asserts that this resulted in a new line. Replacing “\n” with System.lineSeparator() is the cross platform fix, as it will retain “\n” in mac/linux and use “\r\n” in Windows.

For any other Australians amongst us, there’s one other error you’ll see on the console that doesn’t actually affect any tests but creates quite a bit of noise, it happens whenever / is used as a Sensor input. It’s because it contains a row with a local date that doesn’t exist in Australia due to daylight savings switch in October.

These are minor and I’ll look to submit a pull request over the weekend.

1 Like

Issue logged:

1 Like

Hi @jimmyw,

Thank you very much for looking into this! I suppose we could delete the contents of the directory and leave the directory itself? The newline character is a good catch!, thanks!

Is there any chance you could isolate the row with the bad time and change it in the data files?

Anyway, great work!

No worries @cogmission, I’ve taken that approach - PR is here:

Re the row, it could manifest for different rows in any state/country silly enough to use daylight savings time. So I think I’ll take the opposite approach and override the java timezone under junit.

Will address this separately under

Curious to see how that works! (Overriding the timezone under junit). Sounds good, I look forward to your fix! :slight_smile:

I added some notes to the first PR, having to do with our contributor’s license and merge policy… Have a look-see?


Ooops, didn’t watch the contributor instructions video before opening the PR…closed it and opened another one.

1 Like