Updating MCP mappings in ForgeGradle

snapshot.gradle

afterEvaluate {
	["forge", "fml", "liteloader"].each { fgPluginName ->
		if (project.plugins.hasPlugin(fgPluginName)) {
			def fgPlugin = project.plugins.findPlugin(fgPluginName)
			def mcpSnapshotsDir = fgPlugin.delayedString("{CACHE_DIR}/minecraft/snapshots/{MC_VERSION}/").call()
			def confDir = fgPlugin.delayedString("{USER_DEV}/conf/").call()	// UserConstants.CONF_DIR

			def suffix = fgPluginName[0].toUpperCase() + fgPluginName.substring(1)
			def taskName = "copyMcpSnapshot$suffix"
			task(taskName, type: Copy) {
				from mcpSnapshotsDir
				into confDir
				include '*.csv'
			}

			tasks[taskName].mustRunAfter extractUserDev //,extractMcpData
			tasks.genSrgs.dependsOn tasks[taskName]

			fgPlugin.getExtension().mappingsSet = false
			fgPlugin.getExtension().setMappings(null)
		}
	}
}

TUTORIAL.md

Updated mappings for Forge/FML development with ForgeGradle

Official support for updated SRG->MCP mappings is already completed, but in the event that you require local mappings, this 'hack' can serve to inject your own custom mappings faster than the official schedule.

Requirements

For Forge/FML, you will need to know basic directory management and git.

For LiteLoader, you will need to know the structure of Maven repositories, inspecting raw JSON files by hand, MCP's build tools, compiling LiteLoader from SVN sources, ANT, and some Google-fu.

Introduction

The MCP mappings distributed by Forge/FML are encoded in CSV format and extracted to the Gradle cache directory at ~/.gradle/caches/minecraft/net/minecraftforge/forge/<version>/unpacked/conf/. The naive approach of replacing fields.csv and methods.csv won't work because extractUserDev will detect that the cache has changed and will overwrite your CSVs. Without going into much detail of the ForgeGradle build process, it is enough at this time to copy the CSVs right after the extractUserDev task and before the genSrgs task for ForgeGradle to use them throughout the rest of its process.

However, the mappings must be formatted such that the client/server SRGs are merged: the old MCPBot's test CSVs needs an extra step whereas the new MCPBot_Reborn's test CSVs are ready out of the box.

1. Prepare CSVs

New MCPBot_Reborn

Download all three CSVs from the Test CSV site ( http://mcpbot.bspk.rs/testcsv/ ). These are already pre-prepared, and you don't have to do anything further with them.

For all intents and purposes, the new bot has succeeded the old bot, so you'll want the mappings from this bot.

Old MCPBot

MCPData ( https://github.com/MinecraftForge/MCPData ) is a project that was meant to provide MCP snapshots to ForgeGradle, but is currently unused. With recent versions of Gradle, you will also want to apply a version bump as referenced in PR#1 ( https://github.com/MinecraftForge/MCPData/pull/1 ). Once you have it cloned, run the createSnapshot task. There should now be a data/ folder with CSVs that have a side of "2" instead of the usual "0" or "1".

2. Stage CSVs

I had to pick a constant location to copy CSVs from, which is ~/.gradle/caches/minecraft/snapshots/MC_VERSION. Create that directory for your desired MC_VERSION (1.7.10/ for 1.7.10, etc.) and copy the prepared CSVs there.

3. 'Hack' your project's build.gradle

Now we need to inject a copy task at the appropriate location during setup. Download snapshot.gradle and place it as a sibling of your project's build.gradle. Right after your apply plugin: 'forge' line, write apply from: 'snapshot.gradle'.

You also need to remove any mappings= line so that the built-in snapshot support isn't triggered.

4. Re-run setup

Now when you run your setup of choice, you should notice a copyMcpSnapshot task after extractUserDev and before genSrgs. If so, it was a success and you should notice that the forgeSrc jars reflect the new mappings!

Implications

ForgeGradle at the moment caches one set of jars for any single Forge version. This means that by modifying this set of jars, any other projects using this Forge version will also be using this new set of jars, even if they did not apply snapshot.gradle. To revert to the distributed mappings, running setup on an 'unhacked' project should update the cached jars accordingly. However, this means that the 'hacked' project will be using the old distributed mappings, so you will have to re-run setup on a 'hacked' project to use the latest mappings again.

Updated mappings for the LiteLoader plugin

We will need to provide a deobfuscated 'MCP' jar with updated mappings if we want to use this hack with the LiteLoader plugin. This jar used to build against is downloaded during build from LiteLoader's Maven repository by querying its POM file, so to get ForgeGradle to use our updated jar, we will exploit Gradle's dependency resolution rules (see http://www.gradle.org/docs/current/userguide/dependency_management.html ) by specifying our own Maven repository:

Modules from earlier repositories are preferred over modules in later repositories.

Note that the following will be describing general goals rather than specific steps to take, because I, the author, use a custom build process that won't work line-for-line for anyone else.

1. Prepare an MCP jar

You will need to provide an updated jar equivalent to the latest mcpJar listed in versions.json ( http://dl.liteloader.com/versions/versions.json ). At the time of this writing, that is liteloader-1.7.10_02-mcpnames.jar.

There are a few ways to do this but one way is with ANT and extra tasks that pull the deobfuscated output from MCP's bin/minecraft/ directory. For an authoritative listing of files that you need to include, I suggest taking a look at the mcpJar hosted on LiteLoader's Maven repository.

2. Upload to a (local) Maven repository

You will need a Maven repository with a POM file for this updated jar in order for ForgeGradle to find the jar.

One way is to use Maven's deploy-file goal for an untracked jar ( https://devcenter.heroku.com/articles/local-maven-dependencies ), but Maven is required on your system. For example, if you have liteloader-1.7.10_02-mcpnames.jar in the current working directory, the following will create a repository that mirrors the structure of LiteLoader's repository:

mvn deploy:deploy-file -Durl=file://path/to/local/liteloader/maven/repo/ -Dfile=liteloader-1.7.10_02-mcpnames.jar -DgroupId=com.mumfrey -DartifactId=liteloader -Dpackaging=jar -Dversion=1.7.10_02-mcpnames

With Gradle, you might have luck adapting from the following or related: http://stackoverflow.com/questions/11504430/gradle-how-to-upload-custom-jar-file-to-maven-repository

3. Add the (local) Maven repository to your project's build.gradle

Inside your project's repositories {} closure, add this (local) Maven repository as a new entry. For example:

repositories {
    maven {
        name = 'local'
        url  = 'file://path/to/local/liteloader/maven/repo'
    }
}

Then the next time you run build on your project, Gradle will find your jar first by the dependency resolution rules and use it instead of the one on LiteLoader's repository. Success!

Disclaimer

Everything you do here is at your own risk. This is also an unsupported hack that is likely to break if ForgeGradle changes, so don't expect any help from AbrarSyed & co. at Forge.

In ForgeGradle 2.1, MCP snapshots are now natively supported.
minecraft { mappings = "snapshot_YYYYMMDD" }

This has not been tested or implemented for LiteLoader development yet.