[0.3] Lets talk abstracting loom away from Minecraft

NZSmartie commented 5 years ago

Some of you may have heard that I've been working to port Loom over to StarMade. One key component is loom as it download's the appropriate mappings, sets up Mixin Annotations during the compile task, etc...

The request for loom to be more abstract is sparked from fabric-loader 0.4 becoming less specific to Minecraft in terms of loading mods. As it's successfully been used used to load mods into StartMade.

Asset/Libraries

Minecraft
- A Version Manifest JSON file to get all versions of the game
- A version JSON file that lists
- All libraries
- Downlaods (client,server)
- And link to Asset index
- Asset indedx lists each assets' name, hash and size.

StarMade

Has a releaseIndex that can be treated as a manifest.
Not formally formatted (space and # seperated version,date and base download URL)

Example: (http://files.star-made.org/releasebuildindex)

0.201.363#20190214_171006 ./build/starmade-build_20190214_171006
0.201.364#20190219_163910 ./build/starmade-build_20190219_163910
0.201.370#20190316_235125 ./build/starmade-build_20190316_235125

The version index is another space seperated file that lists all downloads,libraries and assets with to classifier.

Example: (http://files-origin.star-made.org/build/starmade-build_20190316_235125/checksums)

./lib/transaction-api-1.1.jar 15071 2ca09f0b36ca7d71b762e14ea2ff09d5eac57558
./lib/tempus-fugit-1.1.jar 55953 4f47af53091985a3e3581af60e432a556a69e2cd
./CrashAndBugReport.jar 54344 2f5850c6e10970a478a04b132fcf0584541ae2da
./version.txt 25 90b3e489aa4a88194c40cd3c917b5086521af02b
./third-party/SoundSystem LibraryJavaSound License.txt 1169 a1cf8b235cbd396c250b9f0908d3630c4ea2e616
./StarMade.jar 11231897 391336baf73722ca87336278a2ccfb40b414b3bd

With AssetIndexJson, VertsionInfoJson and VersionManifestJson classes, i've added a static method to parse the above and add entries based on file type. However this is isn't the best approach for the long term.

Merging Jars

StarMade only has a single game jar that provides both Server and Client modes. At the same time if playing singleplay or hosting a multiplayer lan.

I've removed the merge jars task in the fork of loom for StarMade, but this could be made an optional step.

The Loom extension `minecraft`

This could be renamed to just loom when used in the build.gradle script.

minecraft { // This can be renamed to loom. And have another field to quickly select a minecraft configuration.
    version = project.minecraft_version
    mappings "net.fabricmc:yarn:${project.yarn_mappings}"
}

Unless it's possible to configure multiple gradle extensions, one per supported game that sets up (enables/disables) tasks in the loom plugion.

These are my thoughts so far and I welcome any feedback on ways to move forward or if it's better to maintain a fork and merging changes from upstream.

NZSmartie commented 5 years ago

Mentioned briefly in IRC that asset management for particular games should be decoupled into plugins that are used by loom.

Each plugin for loom could

List supported games/version ranges
List jars that are to be merged (if any) before mapping
Provide latest game manifests for libraries and assets.

loom {
        target "minecraft" // Name of plugin, or supported game that is listed by plugin
        version "1.13"
        mappings "net.fabric.yarn:1.13.6"
}

thought to add it here to help keep track of ideas.

Chocohead commented 5 years ago

Just to expand on the multiple plugin idea so that it doesn't get forgotten in the IRC past:

I'd say that the abstract and Minecraft specific plugin style that Loom 0.2 went for is better for supporting more games than the single monolithic plugin Loom 0.3 now has.

The game specific plugins can all be exported together in the single Loom jar by specifying them all in the build.gradle, then be directly referred to by name so another game's specific tasks and utilities don't have to be added if not needed. This also carries the advantage that a target property could be avoided on the Project extension by simply having the plugin use the game name. Thus:

plugins {
    //Using the theoretical Minecraft Loom plugin
    id 'fabric-loom-minecraft' version '0.3.0-SNAPSHOT'
}

//Allows defining the version and mappings on a minecraft object
minecraft {
    version = project.minecraft_version
    mappings = "net.fabricmc:yarn:${project.yarn_mappings}"
}

plugins {
    //Using the theoretical StarMade Loom plugin
    id 'fabric-loom-starmade' version '0.3.0-SNAPSHOT'
}

//Allows defining the version and mappings on a starmade object
starmade {
    version = project.starmade_version
    mappings = "net.fabricmc:yarn:${project.yarn_mappings}"
}

It could even allow multiple games to be used from a single Gradle project by applying multiple plugins at once, although that might be pushing the limits of how Loom currently handles some things like mappings without cleaner (task) namespacing.

covers1624 commented 5 years ago

My plan for this is exactly what Choco has stated, a separate plugin for each 'pipeline'.

modmuss50 commented 3 years ago

Loom is highly tied into minecraft and I dont see much benefit to doing this huge amount of work. I dont see this ever happening.

FabricMC / fabric-loom