Travis configuration improvements

[wborn]

This PR makes it possible again to follow progress of a Travis build while it's running. While building it shows the reactor progress information while making sure the build doesn't timeout by appending zero width characters every 3 minutes.

While I was at it I've made some other configuration improvements as well:

• Uses the new Xenial Travis images which easily allows for running Java 11 builds
• Builds using OpenJDK 8 instead of Oracle JDK 8. Oracle JDK 8 is no longer available in the Xenial images. I've done a lot of builds already with it and it works equally well.
• Adds a new OpenJDK 11 build which is allowed to fail. This makes it easy to see what needs to be done for successfully compiling the code with Java 11. It disables the enforcer for the Java 11 build.
• On successful builds only the reactor summary is printed (instead of the most recent 200 lines)
• Removes JVM options that are no longer supported in Java 8 and which result in warnings:
  -XX:PermSize=512m -XX:MaxPermSize=1g
• Removes the unused Paper UI NPM cache from the build

I've also tested a similar configuration with the openhab2-addons build (see this wborn/openhab2-addons build) where the timeout would occur during feature validation. The build times remain the same with this configuration.

[maggu2810]

I am fine with the changes in general.

I can't believe that the build time is the same if we are building for 8 + 11 now instead of 8 only.
How is it working? Are the Xenial VMs more powerful?

Does it make sense to enable a build for 11 as long as we are using Xtext <2.17?
Can it ever succeed without bumping Xtext?

[wborn]

How is it working? Are the Xenial VMs more powerful?

It uses a build matrix so Travis typically builds these jobs in parallel. We use an even bigger build matrix for openhab-docker where Travis always executes 3 jobs in parallel. The Java 11 job currently always fails before the Java 8 build succeeds so it shouldn't increase the Travis (wall clock) build time.

Does it make sense to enable a build for 11 as long as we are using Xtext <2.17?

I think it does because it makes it easy to see what other issues there are. E.g. it now fails because of some Mockito issue that needs further investigation. Another reason for adding a Java 11 build is that it shows that we are actively working on supporting newer Java versions which is food for community topics. It also helps to keep the discussion going so we actually get there (like SAT warnings nag people to fix them 😉).

I wasn't aware that Xtext needs to be updated for supporting Java 11. It wasn't mentioned in eclipse-archived/smarthome#4369. Apparently Xtext 2.17 has only been released last week (announcement). Do you think we can easily upgrade Xtext from 2.14 to 2.17? The upgrade should also fix an issue with the xtext-maven-plugin when running a parallel maven build (see eclipse/xtext-maven#37 by @pfink).

[maggu2810]

@wborn I don't know at which placed I reported it. Just found this one: openhab/static-code-analysis#325 (comment)

[cweitkamp]

Do not forget to edit the version constraint in the pom.xml:

[WARNING] Rule 0: org.apache.maven.plugins.enforcer.RequireJavaVersion failed with message:
Detected JDK Version: 11.0.2 is not in the allowed range [1.8.0-40,1.9).

[wborn]

I'd prefer to only do that when we know the code successfully builds using JDK 11. That way it's immediately clear for developers what JDK needs to be installed for a successful build. In the Travis config I've disabled the enforcer with extra_maven_opts only for builds that aren't using openjdk8.

[maggu2810]

@wborn To skip something, so changing the default behaviour should be only done if really wanted.
Wouldn't it make more sense to skip the enforcer plugin if the used JDK is the one we know to skip it (openjdk11) instead of skip it if it is not "openjdk8"?
Sure, it should not matter, just thinking about it.

[maggu2810]

Do you think we can easily upgrade Xtext from 2.14 to 2.17?

I could never get used to it.
Perhaps someone would like to give it a try (we could track it in a separate issue).

Anything missing in this PR or ready to be merged?

[wborn]

It's ready to be merged. :-)

[wborn]

Perhaps someone would like to give it a try (we could track it in a separate issue).

When time permits I can give it a try. There's now #646 for this.

[maggu2810]

Thanks