Module experiment - build harness

[Cervator]

Setting up PR for easier overview and to have somewhere to put notes. Note that this is just very recent work, there is other new stuff in this fork prior to this PR, and somehow this repo is already 800 commits behind upstream, sigh :-) (note: master is effectively my develop here ... err, yeah. It could be clearer)

The main goal to this piece is reorganizing some of the Gradle and template file stuff to both make things cleaner (collapsed two dirs into /gradle that won't be interesting to most users) and to allow an easy way to assemble a build harness zip that can be dumped on a standalone module directory to allow it to build using the exact same build files.

The reasoning behind that is two-fold:

• Allow Jenkins to more easily acquire the build files needed to run a module build (remember: module repos are not allowed to have build scripts) - this way Jenkins can just fetch a zip rather than worry about having the engine job archive a bunch of loose files then copy them in first
• Allow a user to run a module build locally without an engine workspace. This may seem silly at first, since why wouldn't you just use an engine workspace?
  • The main repo is getting pretty chunky - it can take a long time to clone especially on weaker connections. This way you just need a single game zip (or even less - see below). Previously you could mod assets easily enough but it was some hassle to manually copy in stuff needed to compile
  • A new function will be added so groovyw module init will initialize the build harness as a module dir, name taken by the parent dir. Add assets + code, gradlew jar, copy jar into regular game module dir or share it with a friend
  • Occasionally we need to actually see how a module builds / publishes solo. Usually for testing something that may have an impact on Jenkins

It may even be possible to include a command that'll run the game right out of a standalone module directory. After all the Gradle already depends on the engine jar and so on. So it might be possible to not even have a full game dir, just whatever Gradle fetches from Artifactory

One additional major issue is being experimentally addressed: when a solo module build does run it tends to fail if there are environment-based unit tests present, because execution ends up starting in the Gradle cache. I came up with a check for PathManager that seems to get you back to the module dir, and the process now gets past that part, but oddly seems to fail on some module sandbox setup issue now. Am curious if @kaen or @oniatus might have a clue there.

Note that to run this I recommend a separate workspace - do not try this at home (in your regular workspace) :D

The gradle.properties in the template dir may be needed to make sure configuration on demand is off. I'm working split away from the regular MovingBlocks and Terasology orgs, in Artifactory as well. One other issue is that modules retrieved from Artifactory will tend to come with a dependency on a specific version of the engine, which can make it harder to test things when you have related changes in a local source engine. I've got some clues on how to fix that as well but in the meantime have used bumping the engine version to 1.6.1 then using gradlew engine:install to get a newer version in my local cache that'll get used instead of something from Artifactory without my changes.

Right now this just works in Gradle. I had clues to fix IntelliJ but it brings a lot of hassle, in particular without any sort of IntelliJ customizations (just standard Gradle stuff)

Next up I'll be testing this in Jenkins with new pipelines. Lots of stuff still to do but it is looking promising.

[GooeyHub]

Jenkins Failure Message