Add API for versions manifest providers and version metadata providers

[SpaceWalkerRS]

Adds an API allowing third party plugins to provide their own versions manifest and version metadata. This is done through two new providers: VersionsManifestProvider and VersionMetadataProvider. Each can be set independently and will be stored in different cache files so as to avoid issues when using different manifests for different projects.

The default manifest provider downloads Mojang's manifest and stores it in ~/versions_manifest.json.

The default metadata provider stores the metadata in ~/<minecraft version>/minecraft-info.json. It has a versionMetadataUrl property that is meant to replace LoomGradleExtension#getCustomManifestUrl, and will be used if it is present. Otherwise a version lookup is done inside the manifest and the URL is taken from that.

[modmuss50]

Quick question: Whats the intended use case for this?

[SpaceWalkerRS]

It might be more relevant for old version modding than for modern versions. The further back you go, the more versions are missing from Mojang's manifest, like all snapshots prior to 1.5.2, but also some releases in the beta stage. Being able to use a custom manifest that references versions that Mojang don't have but are archived elsewhere would be nice. Loom does allow overriding the complete manifest through an extra property but it uses the same cache file so if anything in it does not match Mojang's manifest you can be in trouble when switching black to a modern version project.

I've also seen devs run into issues when switching between Ornithe b1.7.3 and Babric b1.7.3, because both use a different manifest, so switching between projects requires clearing the cache. With this API we can keep our manifests separate so devs can cleanly use both projects if they wish.

[modmuss50]

I've also seen devs run into issues when switching between Ornithe b1.7.3 and Babric b1.7.3, because both use a different manifest, so switching between projects requires clearing the cache.

I havent looked at it in detail yet, but this seems to be a lot of code and complexity to fix this. My inital idea to fix this would be to just include the hash of the manifest in the filename + AbstractMappedMinecraftProvider.getName/getVersion.

Why do you need both a metadata and manifest provider? Surely you just need to impliment the manifest provider, and a plugin can choose to have its own metadata or not?

Out of intrest why do these two projects have diffrent manifests? Is it something we could put on our maven in a similar way to the experimental versions?

[SpaceWalkerRS]

I havent looked at it in detail yet, but this seems to be a lot of code and complexity to fix this. My inital idea to fix this would be to just include the hash of the manifest in the filename + AbstractMappedMinecraftProvider.getName/getVersion.

Hmm I really overthought this didn't I 😄 - yeah I think that'd be a suitable solution. Though it'd be nice if Loom would expose the manifest currently in use (in addition to the metadata that can already be queried from the minecraft provider).

Out of intrest why do these two projects have diffrent manifests? Is it something we could put on our maven in a similar way to the experimental versions?

As for Babric, I think they use custom metadata, to which they add their own libraries and replace some of Mojang's. Ornithe uses Skyrising's manifest, which has more versions, and provides not just a metadata json but also an extra 'details' json.