Even more good progress today, after re-thinking approaches a time or two.
There's a
working application distribution in Jenkins now, although it (on purpose) excludes all modules. I think of it more as a "PC harness" that an actual game package job would use as a base then overlay with a set of content modules. It actually runs, too, you just can't create a world as there's no Core module etc. You can fetch it as a
subset of the attached artifacts
I cheated and during app distribution rename the PC jar file to "Terasology.jar" although this one just contains one whole class and a somewhat hacked together manifest that allows it to find all the lib files (which includes the engine.jar)
On top of that I think I've got an interesting approach to putting together game mode distributions. I've added the beginnings, ran out of time actually taking it to the next step with a ModeZero assembly job using it. Here's
Core's module.txt:
Code:
{
"id" : "core",
"version" : "1.0.0",
"displayName" : "Core Gameplay",
"description" : "This module introduces the core Terasology mechanics",
"optionalDependencies" : [
{
"id" : "BlockNetwork"
},
{
"id" : "Signalling"
}
]
}
The optionalDependencies (exact name?) are meant as modules relevant to this particular module's interests. I'll make Gradle smart enough to where the optionals will be fetched just like normal dependencies (source, local binary, Artifactory) although missing one probably wouldn't be a fatal error. Easy way to then use "gradlew addModuleCore" to in one go get the Core module in source and every other listed module in binary form. Then selectively override the ones you care about with source, if wanted.
Likewise in Jenkins that could be used to build a ModeZero app zip or a "ModeOmega" app zip that would have a much larger module list when we have more to play with. The Launcher could fetch the PC assembly from the engine job as the base game then offer those game mode distributions as "mod packs" or what not in its GUI. Pinging
mkalb MrBarsack &
Skaldarnar 
By the way, do you guys still use the following bit from the build jobs or have the bundled version info taken over?
Code:
echo "$BUILD_NUMBER" > /home/movingblocks/httpdocs/updater/multi.ver
On top of that I envision a "strict" setting in a game mode definition (within a module, like the first round of Light & Shadow) that'll treat the optionalDependencies as an "allowable modules" list for said game mode, disabling all other modules when that's the chosen game mode. Normal dependencies will still be the only ones that'll be mandatory. After all not all modules will make sense in Light & Shadow. There'll probably be a way to override, but anyway, seems like it would be useful. What do you think,
Immortius ?
That's it for now, getting late. This is
exceedingly close now and I was thinking I'd do a final application to a multiplayer branch on Saturday for review and replace develop with the restructure if all appears well next day. I would appreciate any review in the meantime of the Gradle magic (can test with the line-up in the above post - still needs polish, of course) and the
remaining issues listed for the restructure to see which would be absolutely needed before a merge
Of course - on the other hand I just realized the whole licensing / contributor agreement thing sort of went idle, and while "Apache all the things" for the stuff we've got is fairly straight forward and doesn't even take any substantial changes I imagine I've still got some doc work and other fun things I should probably get out of the way ASAP. Wee
