Hand SlimeLauncher the extracted metadata zip, cache extraction - #1084
Hand SlimeLauncher the extracted metadata zip, cache extraction#1084PaintNinja wants to merge 1 commit into
Conversation
- Avoids needing to re-extract it every launch from SlimeLauncher's end - Zip extraction is now cached by Gradle's build cache feature across builds with the same metadata zip
LexManos
left a comment
LexManos
left a comment
There was a problem hiding this comment.
This would also need the ForgeDevPlugin side of things.
| } | ||
| this.getFileSystemOperations().sync(spec -> { | ||
| spec.from(this.getArchiveOperations().zipTree(archive)); | ||
| spec.into(outputDir); |
There was a problem hiding this comment.
Just for note, this technically causes the entire zip archive to be extracted to disc twice due to how zipTree is implemented in gradle. Once in their zipTree cache and then to the output directory.
There was a problem hiding this comment.
Is there another way that would be preferred over this?
There was a problem hiding this comment.
The old code extracts just the files needed, do file locking. Its a trade off of which part you care about. It would probably be worth doing a matching('launcher/') to emulate the filter we had before. But the metadata zip doesn't contain much in it.
|
|
||
| protected abstract @InputFiles ConfigurableFileCollection getMetadata(); | ||
| @PathSensitive(PathSensitivity.NONE) | ||
| protected abstract @InputFiles ConfigurableFileCollection getMetadataZip(); |
There was a problem hiding this comment.
This is a breaking DSL change, i'd keep the property named getMetadata so that we don't have to worry about that.
2 participants
I think this is the only task runs after configuration time that could be cached - if so, this PR also implements #993 as FG7 core now intentionally supports Gradle's Build Cache for this task.