Lessons learned "JUnit 5 compile and test on Java 9 b162"

Links

Discuss additional information tag stating location from where an engine was loaded from - or remove TODO [10]
Include Gradle Shadow 2.0.0 [4] - remove jfrog.org/artifactory from repositories
Include AssertJ 3.7.0 [5] - remove jitpack from repositories
~~Report and~~ remove workaround for ServiceLoader "bug" when "everybody" has access to build 163 [9] [9.2]
Merge main Java 8 and this Java 9 build into a single .travis.yml script
junit-jupiter-migration-support is excluded from the build; it suffers from duplicate test engines present in the classpath. Scan and fix: junit-jupiter-migration-support.gradle Solved by workaround [9]
junit-platform-gradle-plugin is haunted by GroovyCompile Gradle Daemons. [2] Solved by using _JAVA_OPTIONS

Gradle 3.5 or higher -- Groovy 2.4.10 includes bugfixes that enables running on Java 9. Groovy 2.4.7 included in Gradle 3.4 and below has issues with finding basic methods in classes from jdk modules.
ASM 5.1 or higher -- older ASM versions may produce bytecode, that is no longer runnable on Java 9. See [3] for details. Beware, other tools like the Gradle Shadow plugin [4] or AssertJ [5] package ASM into their library. Both tools will release an official version, soon.
Use jitpack [6] when a github-hosted project does not provide SNAPSHOT versions of their tools but an branch exists, that already contains Java 9 related fixes. Like internal ASM upgrades.

some external tools, like google-java-format (used by spotless) do not run on Java 9, yet. Skip them and wait for an update.

[1] https://docs.gradle.org/current/userguide/gradle_daemon.html#when_should_i_not_use_the_gradle_daemon "It is recommend to disable the Daemon for Continuous Integration and build server environments."

[2] https://github.com/gradle/gradle/issues/1461#issuecomment-284422560 "There are two different "daemons" in play here. There is the "Gradle" daemon and then there are compiler daemons."

[3] https://bugs.openjdk.java.net/browse/JDK-8174868 "javac has never generated inconsistent constant pool entries, but some bytecode generating software may."

[5] https://github.com/joel-costigliola/assertj-core/issues/968 "We have upgraded in master cglib to 3.2.5 and asm to 5.2" "BTW, we are planning to release the next version of AssertJ 3.7.0 at the end of the month."

[8] https://travis-ci.org/junit-team/junit5/builds/219251561#L752 "ReflectionUtils.java:837: warning: [deprecation] isAccessible() in AccessibleObject has been deprecated // if (!object.isAccessible())"