More Gradle follow-up, more focused on code analytics #3856

Cervator · 2020-03-16T05:32:22Z

Although it may also hold some promise in fixing some quirks due to how with Gradle 6 we got a new default target build path (build/classes/java/main instead of plain build/classes) - turned out there were more places where that mattered than the few I found and tried to apply fixes for.

This PR specifically fixes the ModuleTestingEnvironment, which for some reason failed to find any world generators as the test for which module provided one would run into one path with the java/main fragment and one without.

I tried to puzzle that out for a while but didn't really get anywhere. This solution may not be perfect (somewhat going backwards) but it reduces uncertainties while we improve stuff further and find the time to make more proper fixes. I expect a next big round might be when we switch 100% to Gradle vs using any IDE-specific stuff.

This restores how Gradle and IntelliJ builds to the same paths (both regular source and test source, to a different spot each) so that in theory stuff should work the same via Gradle as in IntelliJ (... and good luck with Eclipse or Netbeans). Ultimately we should delegate all building, run configs, etc to Gradle, at which point we might be able to fix some of these quirks. Others may take some classpath tweaking in Gestalt - maybe delay that till the reintegration of the latest release?

Goes with:

Add initial recording of test results and other analytics ModuleJteConfig#2 - updated module build file (at least demonstrates some stuff, needs more work)
Two different fixes: Better package + split a test Terasology/Health#37 - found another couple spots where tests depended on packages no longer normally available in the engine, fairly easy fixes
I am not convinced this affects the mystery world generator resolution issue we're having these days, although I can't tell since it isn't happening for me right now. Pinging @sin3point14 to maybe try this out and see if there's any difference?

Outstanding:

For some reason the engine tests in TypeRegistryTest intermittently stall for me, both in Gradle and in IntelliJ. Sometimes I've been able to run the first one to completion even if it stalls for a minute or two, other times they just hang. Anybody else able to try it out on other OSes might be informative (I'm on Win10)
Two of the MTE tests still fail, but seemingly from getting stuck in an infinite loop in LocalChunkProvider.checkForUnload() - huh? Not sure that'd relate to these changes. ClientConnectionTest and ExampleTest - the others work fine now.
Module tests in Jenkins still fail, as is tradition, thanks to Better isolate involvement of OpenVR regarding FirstPersonHeldItemMountPointComponent #3415 - confirmed via Health, although its MTE tests do work locally now, honest!
Got a local fix for ItemPipes as well
Need to enable the analytics visualization in the engine, just started in a module since way faster build time.

Pinging @DarkWeird for possible interest

…e output files go (and thus where they get accessed/scanned from) It turned out several places expected the old path in the build/classes dir, may be easier to restore old behavior like this until we're ready to rework Gradle further and make IDEs use it directly and/or re-integrate Gestalt and deeply examine its classpath scanning

… seems to matter, varies in engine vs module workspace)

GooeyHub · 2020-03-16T05:47:10Z