Use different cache files for custom manifest and metadata jsons

FabricMC / fabric-loom

Gradle build system plugin used to automate the setup of a minecraft mod development environment.

MIT License

223 stars 194 forks source link

Use different cache files for custom manifest and metadata jsons #1077

Closed SpaceWalkerRS closed 2 months ago

SpaceWalkerRS commented 3 months ago

This PR serves to replace #1069 and resolve the issues discussed within it a different way.

A new API is added where plugins can provide custom versions manifests. All versions manifests (including the built in ones) are sorted in a priority queue so mods can choose let their custom manifests act either as a fallback or to override the built in manifests.
The manifest cache file name gets a hash suffix if a custom versions manifest URL is given through this new API. The hash is computed by calling hashCode on the manifest URL string and converting that to hex.
The Minecraft metadata cache file name gets a hash suffix if a custom metadata URL is given (through the customMinecraftManifest property in the Loom extension API) or if the versions manifest is custom. The hash is computed by calling hashCode on the custom metadata URL string if it is present, or else by calling hashCode on the manifest URL string, and converting that to hex.

modmuss50 commented 3 months ago

I dont think this does replace #1069 as it doesnt really fullfil an API allowing third party plugins to provide their own versions manifest and version metadata imo.

Just to clarfiy/surmise what the requirements are, it would be something like:

A 3rd party plugin should be able to provide its own metadata for a custom minecraft version, that is not present in the default metadata.

Im not sure we want 3rd party plugins hijacking and replacing the mirrors, it wasnt designed with this in mind.

SpaceWalkerRS commented 3 months ago

Im not sure we want 3rd party plugins hijacking and replacing the mirrors, it wasnt designed with this in mind.

I see. Perhaps we can add custom properties to the Loom extension API, the same way there is already a custom metadata url property there?

modmuss50 commented 3 months ago

Maybe, I think this is a bit better, but could possibly just be a single ListProperty<String> getAdditionalVersionsManifests();, allowing plugins to register their own manifests alonside the existing vanilla ones? I imagine the vanilla and fabric one should take priority?

SpaceWalkerRS commented 3 months ago

Lists could work for that for sure, I like that idea. But I think the custom manifests should take priority, to make the point of these properties to allow plugins to override their own manifests, but have the default manifests (i.e. the Mojang and Fabric ones) to fall back on.

modmuss50 commented 3 months ago

Ok sure, not tottaly keen on them being able to override, as it will mess up the caches but other than that its not a major issue.

SpaceWalkerRS commented 3 months ago

The lists will require some shuffling around of the logic, 'cause you no longer know which URL is gonna be used, and I used that to change the cache file names.