A toolchain for Minecraft: Java Edition that builds a workspace to interact with the game using the official mappings provided to the public by Mojang Studios.
MIT License
89
stars
18
forks
source link
Redesign resolution to use a local Ivy repository rather than a Gradle task chain #26
This rips apart a whole lot of how VanillaGradle works in order to give us more control over how artifacts are resolved. There's still quite a lot to do in order to make this a solid system, including:
[ ] Figure out the best way to make sure the Minecraft dependency is available on the runtime classpath for IDEs, while not being included in shadow jars. may require explicitly hooking into the shadow plugin (via a compileOnly dependency)
[ ] Add dynamic version parsing to our eachDependency() hook, so a minecraft version can be declared as latest.release, latest.snapshot, 1.16.+, and such
[ ] Validate compatibility with dependency constraints
[ ] Update clean tasks to clear the new repository
[ ] Set up dependency constraints on tool configurations to make sure we're always using our chosen ASM version
[ ] Make sure access-widened artifacts don't show up as access-widened in the pom (or at all?)
[x] Actually validating artifacts and determining when they need to be updated. Inputs (decompiler version, mappings revision, etc) need to be passed to the resolver to determine this partially done, just checks if all inputs are up-to-date as well as the original artifact existing rn, more will come in another pass
[x] Sorting out the Downloader model -- right now it's halfway between a transport abstraction and a cache. The Gson handling needs to be stripped out
[x] Fix version manifest handling to actually cache again (depends on Downloader work)
[x] Restore access widener handling, and figure out how to integrate the root-project cache to support that
[x] Add versioning to metadata files, and the repository as a whole -- not sure if artifacts themselves also need to be versioned, but I think our model of MC metadata may change as time goes on
[x] Add a Settings-level injectRepositories option (and maybe a place to inject extra version manifests there)
[x] Clean up unused tasks from the old pipeline
[x] Update asset downloading to use the Downloader interface, rather than requiring implementation details. Try another approach to asset validation that works better on large asset folders maybe too?
This rips apart a whole lot of how VanillaGradle works in order to give us more control over how artifacts are resolved. There's still quite a lot to do in order to make this a solid system, including:
compileOnly
dependency)latest.release
,latest.snapshot
,1.16.+
, and suchpom
(or at all?)Downloader
interface, rather than requiring implementation details. Try another approach to asset validation that works better on large asset folders maybe too?Fixes #24 Fixes #22