Incorporate ModuleManager

[skaldarnar]

Incorporate the Terasology/ModuleManager into the launcher GUI.

This allows for selective updates of game modules (see #120) and general module management (see #118).

[msteiger]

I did some investigation on the issue which lead me to Sonatype/Apache/Eclipse Aether. It's a set of libraries that allow for querying, downloading and even uploading Maven artifacts such as jars to and from a Maven repository.

In one of the first tests, I successfully used Aether to resolve all dependencies of "ThroughoutTheAges" on Terasology's Artifactory server.

Next steps would be to support downloading modules to a given folder, but that should be rather easy.

I believe that this functionality should be wrapper in a separate library and not part of the launcher. I suggest re-using the deprecated ModuleManager library (which was experimenting with jgit) for that.

Ping @Cervator

[Cervator]

Unless Aether can be configured to use custom origins other than current style artifact repositories (Nexus, Artifactory, etc) I don't think we can use it - our Artifactory isn't meant for public use, just devs. It would get overwhelmed and crash at the first whiff of a traffic spike from the internet. Heck it crashes every few weeks currently :-)

A potential alternative would be pushing our artifacts forward to Maven Central or Bintray, but that doesn't seem right, might outright violate some policies (GitHub is at least meant for releasing software), and might eventually not work at all (if somebody wanted to release a premium closed source module they could do so on GitHub but not Maven Central). Not to mention the packaging requirements differ between artifact repositories and the more free-style GitHub

My intent with ModuleManager was always a custom implementation likely using the Index repo as a sort of database (as opposed to anything in Jenkins or git cloning multiple things), with jar locations via releases on GitHub, so both spots bypass our meager infrastructure. At least until GitHub yells at us, but I suspect such a day, if it ever comes, is a long ways off

It is possible we could structure it well enough to where you could reuse some existing libraries / frameworks of some sort, maybe similar to package managers like Yum (which with some tweaking you in theory can make stuff like Artifactory behave like). I certainly would like to see us effectively support alternative "module sources" for adventurous players that could be hosted by others on GitHub or somewhere completely different.

In any case we still need to even release things to GitHub in the first place. And figure out more about Distros :-)

[msteiger]

I think that using a repository system such as Maven would be ideal for module management.

• It maintains jar files
• It supports both snapshot and release builds
• It provides different versions of a jar file
• It performs dependency resolution
• It supports deployment from Jenkins
• It supports downloading jars to clients (including deps)

Imho, it has everything we need and it's already all set up! Artifactory already has the module jars and serves them happily. Besides, I also would not want to rely on GIthub infrastructure more than we need to.

What do you think about getting Artifactory more robust / stable? Why does it even crash all the time?

One viable alternative would be Bintray. It could host a public Maven repository with all our modules (just like Artifactory).

[Cervator]

Making Artifactory (and other of our servers) a little more stable is easy enough - add weekly restarts, tweak the setup a bit (I think Artifactory uses Tomcat, it could probably use Jetty to conserve resources), add more horsepower if needed. Right now it is probably weak from low resources.

It'll still fall over at the slightest traffic spike, however, we can't guard against that without a very impressive dynamic load balancing setup, which would then make my wallet fall over :D

[skaldarnar]

Related to #118

[skaldarnar]

Closing as Mod Management is done by the game itself.