Integrate JAMMER for use in porting across MC versions

[sciwhiz12]

Currently, porting of the mappings data between Minecraft versions is done through a deliberate 'side-effect' between the export system and the inputs system. The current mappings is exported into a JSON using an intermediate mapping, then the new version mappings data is created through the input system in an environment configured for the new Minecraft version.

This has worked successfully for the past few times we've ported to new Minecraft versions. We currently use the SRG intermediate mapping (provided by the MCPConfig project) to port mappings, but Compass is designed to allow the use of other intermediate mappings if necessary -- even Mojang mappings directly (though that comes with some pains due to the changing nature of human-readable names).

We plan to reduce the use of an external intermediate mapping and further automate the porting process by integrating the JarAwareMapping or JAMMER matching tool, developed by @marchermans and primarily used in the aforementioned MCPConfig project for generating SRG mappings for new versions.

The goal is to migrate mappings to a new Minecraft version by giving Jammer the JARs for the previous and new Minecraft versions, and letting it match members from the previous version to the new version, carrying along the mapping data and outputting the resulting matched mapping data at the end. This would hopefully resolve #11, and reduce the work needed to port the mappings, possibly even allow full automation of the porting process when new Minecraft versions are released.

---

Here is a rough outline of the work needed to implement Jammer:

• Refactor and expand Compass' download utilities to allow downloading version manifests and libraries from different Minecraft versions, likely up to task execution time.

• Work with @marchermans to determine what environment and arguments are needed to configure Jammer to perform the porting process. This includes finding blocking issues regarding Jammer's design (as it is currently primarily used for SRG mapping generation) and fixing them as needed. See Support parchment forward mapping marchermans/JarAwareMapping#3.

• Design and implement Jammer integration with the following goals in mind:

  • The version of Jammer and its dependencies can be changed as needed from the buildscript.
  • The arguments fed into Jammer can be changed as needed from the buildscript, for when new Jammer versions add or remove arguments.
  • The use of project or Gradle properties to control the execution of Jammer tasks are limited or avoided entirely if possible, preferring task command line options.
  • The existing porting process as done using the export and inputs system remain, as a backup for porting.