Treat unexpanded Gradle version property as satisfied dependency
This helps when testing mod compatibility with mods that have a dependency on the mod that is being developed.
Another solution would be to set the gradle version from the mod json.
Do you mean loading the version from gradle.properties in ModMetadataParser?
The main problem is that people can use any custom token for substitution; nothing prevents them from using ${myKey} if they do replacement of myKey in processResources. Hence I prefer modmuss' suggestion, which will make some change to the example mod instead, so its gradle buildscript pulls the version from fabric.mod.json.
Gradle has a json parser - you can simply read the file and set the version. Alternatively, you can run processResources before launch. Personally, I use the latter.
This was also previously discussed in https://github.com/FabricMC/fabric-loader/pull/359
The best solution would be to make the generated minecraft run configuration run the gradle processResources task and use that resources indeed, which is the behavior of gradle runClient
Gradle has a json parser - you can simply read the file and set the version.
Ah that sounds even better. I'll make a PR for the example mod.
Fyi I sent a pr, and that works good per my testing
I think I want to do do two things here:
- change example mod to read the version from the json
- add a system property to loader to override the version based on mod id (needs to support more than 1 mod id+version pair ofc)
This way the default just works and the classic approach is fixable as well. I don't like the special casing used in this PR, implementing the option 2 from above should wait until my next big PR is in.
We now have various simple approaches:
- use the actual version in fabric-mod.json, pull it into the build via
version = loom.modVersion(handles all parsing, requires loom 0.10) - overwrite the version loader uses with the system property:
-Dfabric.debug.replaceVersion=modA:versionA,modB:versionB,... - run through gradle as before