In-game d/l of module with dependencies fails to see dependent code exists in IDE, causing loading problems

[RomanCoder]

What you were trying to do

As a developer, I was making modifications to the file healthHud.ui, then running the game from within the IntelliJ IDE. At runtime, my changes were not being seen by the game.

What actually happened

From within the game, I downloaded the 'Breathing' module, which had a dependency on the 'Core' module. The file I was changing belongs to the Core module. Once I downloaded the 'Breathing' module, a Core-1.0.0-SNAPSHOT.jar file was also downloaded, with an older version of the same healthHud.ui file that I was modifying in the IntelliJ IDE. The game at runtime would first look in the jar file, see the older file, and run with that, ignoring my lastest changes version of the same file in the source code.

How to reproduce

• From within the IDE, change the healthHud.ui file. For example, change the "offset" value of the "position-bottom" argument. Save and build.
• Run the game. See that the change you made to the healthHud.ui file is reflected in the game. If you changed the "offset" value, you'll see the health bar move up/down from where it normally is at.
• From within the game, download and activate the "Breathing" module. I'm assuming that you do not already have it loaded when doing this step.
• From the /Terasology/build/ folder, you should see two jars, one for breathing, and one for core. The core jar will have a healthHud.ui file in it, with the original/older values.
• Rerun the game, and notice that the health bar has returned to its default location.
• Exit the game, make further changes to the healthHud.ui file, save/build, and rerun the game. You will not see any of your changes reflected in game.

Log details and game version

Computer details

Linux Mint Cinamon 17.3, IntelliJ IDEA 15.0.4.

[Cervator]

Thanks a lot for figuring that one out! I appreciate the effort, it is definitely a quirky one :-)

[Cervator]

Closing as fixed via #2451's increment of Gestalt to a newer version!

I was able to replicate the original use case by @RomanCoder and verify my change stayed in place even after copying in an unmodified Core jar at the same release level (both were 1.2.1-SNAPSHOT). The source version won.

HOWEVER an important note in which case the old behavior still exists: a binary module of a newer release level will still win over a source module. I took off the -SNAPSHOT from the module.txt in the Core jar and now the binary version won since 1.2.1 > 1.2.1-SNAPSHOT

Same thing goes if the binary is 1.2.2-SNAPSHOT - it still beats source at 1.2.1-SNAPSHOT. But it is probably a fair bit less common that you'll have an outdated source version and a newer binary. Totally can happen, of course, if you left your workspace to go stale then got a newer version from in-game browsing.

The more likely case of having both source and binary snapshots at the same level will now result in a log entry to warn about it. Come to think of it maybe we should also have a log entry for when a newer version wins over an older one, just to make it clear.

This was an important fix, very disruptive issue for development - thanks @rzats ! :-)