Transfer buildscript tasks to another language

[Copetan]

Currently, the Feather buildscript uses Gradle to execute all of its tasks, from running the main feather task, mapping generation, and name propagation, to downloading necessary libraries and publishing the mappings to the Ornithe maven repository. This has mostly worked, but Gradle has a tendency to time out or reset its connection randomly for no discernable reason. This was previously a really significant issue when we would publish every version in the same task sequentially, but #134 has significantly improved that situation by running every publish task in parallel, publishing up to 20 versions at a time concurrently.

This solved the issue of having to restart the whole publish task for every version if one of the versions failed, but the second time the new publish workflow was run, many versions failed to publish because the publish tasks would try to upload an artifact version that was already on the repository, because the maven-metadata.xml file didn't have those versions listed in them. We believe the concurrent nature of the workflow is causing a race condition with reading and writing the maven-metadata.xml file, preventing it from getting accurately updated for every version.

When thinking of ways to resolve the first issue, I had the idea of transferring most, if not all, of Gradle's workload to Pure Java Code; I shelved this idea when @Kahzerx refactored the workflow, but this race condition issue is making me consider bringing up this ussie again.

There are a couple things to consider:

• What are all the tasks that are part of the current Gradle buildscript that we would need to translate to Java? Are there tasks we can get rid of?
• Is there any new functionality that would be nice to add to a potential Java buildscript that was unfeasible to have when we used Gradle?
  • This might be a way that we could publish all the versions without updating the maven-metadata.xml file, until the very end.
• Where are we storing the cache for these tasks, like version jars and the like? Should we try to use the same cache folder that our current Gradle buildscript uses? Should we use a different location?
• Related to the previous point, should we use Gradle as a sort of "bootstrap" to run the core Java code part of this potential buildscript? Or should we ship with a Pure Java Code bootstrap main class that we compile on the fly that runs the rest of the buildscript?

I'm getting to the point where I've written so much that I'm losing track of my thoughts, so I'll stop here, I might edit this more later. Please feel free to share your thoughts about this.

[Copetan]

@zeichenreihe Also has brought up the idea of completely rewriting the buildscript in Rust, so that is another option that we can consider

[zeichenreihe]

I already have #143 that would simplify the gradle buildscript a bit, allowing easier rust building (as in less things done).

One thing we might want to consider is adding superclass information to the mappings files (that would remove needing to download mc jars for getting them for doing remapping or finding bridge methods).

Another thing would be to also let enigma store bridge method mappings in our mappings [graph], which would also remove needing to figure out what bridge methods exist (further simplifiying the build task).

I already have a working rust version of a mapping graph reader, as well as a way to apply diffs to that graph. My current goal was just to provide the "build" task, but I'm sure that can be extended to also support modifications and writes of that graph.

One thing to note about the current gradle way: you read/write the mappings file like 10 times, because every enigma ...Command reads the mappings and writes new ones, reading it once and writing it at the very end removes that overhead.

I'm also gonna say: I currently don't have much time to spend on this "let's build it in rust"... but in 5 weeks there should be more time again.

[Copetan]

I'm also gonna say: I currently don't have much time to spend on this "let's build it in rust"... but in 5 weeks there should be more time again.

Yeah, I'm not expecting anything soon since I don't think very many of us have much time either 😅

[SpaceWalkerRS]

The gen2 branch has moved most of the build script logic into a Gradle plugin (Keratin), and while it doesn't solve every issue, it does make the build logic a lot more manageable. I wonder what issues still need fixing, and what changes we still want to implement, and if we can replace some of the parts that are using Gradle internals with custom Java code or event by invoking native code.