Add Windows build to CI

[JordanMartinez]

No description provided.

[JordanMartinez]

It seems like AppVeyor is either not building the PR or taking a much longer time than normal to do so.

Edit: Turns out it was working on a previous build from a previous PR/commit that was outdated. Once I cancelled the old build, it started building the newer ones.

[JordanMartinez]

Looks like the Windows build is getting stuck on NavigationTests.MultiLineJaggedTextTests.pressingDownMovesCaretToNextLine. My workaround for insuring the TextFlow was properly set up to have 3 lines seems to be the culprit.

[afester]

I have observed this earlier with some other tests running on Windows - the root cause is that
waitForMultiLineRegistration() NEVER returns, means it does not even time out after five seconds in WaitForAsyncUtils.waitFor(5, TimeUnit.SECONDS, textFlowIsReady);. A workaround I tried earlier was to explicitly terminate the while() loop, something like

int count = 0;
while (area.getParagraphLinesCount(0) != 3 && count++ < 500) {
   sleep(10);
}

With that , the test still fails, but at least it does not block forever.

[afester]

Why do we need that "MultiLineRegistration" workaround at all? Is it because of different font sizes/different layouts on different window systems (Mac vs. X11 vs. Windows)? During my earlier analysis, I also simply made the text longer so that it is spread over 3 lines, and the tests also passed ...

[JordanMartinez]

It never returns or times out? Very strange....

The workaround is needed because the tests fail on (corrected: not Linux, but) Mac. The tests would always fail because TextFlow wouldn't return the correct paragraph count immediately after it was set up. So, by waiting for the expected count to be the value returned, then the tests will work. Perhaps we should try running the test without this workaround to see which OS needs it and which do not.

[JordanMartinez]

Hmm... seems it works even on Mac now without that method....
I wonder if splitting up the navigation tests into their respective classes also removed an interference between tests that I didn't know about.

[JordanMartinez]

Since the font is never specified in the test, I'm guessing the tests pass on Linux/Mac because their default fonts are the same but that Windows uses a different default font. Thus, more/less content is being displayed per line than expected, resulting in a failed test.

[JordanMartinez]

It seems the referenced issues are currently blocking the last commit I've pushed to this PR...

[JordanMartinez]

An update to JUnit fixed the problem. Nice.