This thread will provide information and support for using Groovy language in minecraft forge projects. If you don't know what's Groovy, you can read about it here.
Workspace setup
You will need to obtain a special plugin for gradle - 'minecraft-groovy-adapter'. It is hosted at Bintray, so all you need to do is add some lines to the build file:
Don't forget to add a compile dependency on the Groovy itself.
After project refreshing, this plugin will add 2 tasks to "build" category: createClassHierarchy and remapFieldNames. They need to be configured,
so add their configuration closures after minecraft closure:
createClassHierarchy{
}
remapFieldNames{
}
In the first closure, you must set pathToSource directory, which contains currently used minecraft and forge source Jars. Example for Linux systems (might work on Windows, too - haven't tested):
createClassHierarchy {
// get the currently used mappings
String[] mappingsversion = "$project.minecraft.mappings".split('_')
// set the directory
pathToSource=Paths.get(project.getGradle().getGradleUserHomeDir().toString(), 'caches', 'minecraft', 'net',
'minecraftforge', 'forge', "$project.minecraft.version-$project.minecraft.forgeVersion", mappingsversion[0],
mappingsversion[1]).toFile()
}
In the second closure, set the archive property to your mod Jar, and mcpToSrgMap to the "genSrgs" produced file. Example:
After refreshing they should be ready to use, but first make sure you have a Groovy source directory created (delete 'java' directory if there is one, it isn't needed) and write some (or much) Groovy code there. Annotate every Groovy file with @CompileStatic.
Building
When you have finished writing and testing your mod, run "build" as always, then run "createClassHierarchy" and "remapFieldNames". createClassHierarchy will make class-to-superclass mappings and class-to-field mappings. remapFieldNames will use these mappings to create a Jar with a classifier "fixed" from the original Jar. You can change the classifier of the produced Jar to something else.
You also should be able to write mixed Java/Groovy code.
To play the mod, the players will just need to get Groovy library from its binaries from official website and put it into 'mods'.
Under the hood
Groovy uses a thingy called 'meta object protocol' which compiles its code differently from Java. We don't want that, because it "hides" class fields from Forge's obfuscation tasks. So we annotate every Groovy file with @CompileStatic, which makes code to compile almost in the same way as Java does. Groovy also sets fields by their names (similarly to getting/setting a field via reflection), not references, thus obfuscation tasks can't find them. This plugin takes care of finding such unobfuscated fields and obfuscates them.
This thread will provide information and support for using Groovy language in minecraft forge projects. If you don't know what's Groovy, you can read about it here.
apply plugin: 'groovy'
apply plugin: 'alexiy.minecraft.groovy'
Don't forget to add a compile dependency on the Groovy itself.
After project refreshing, this plugin will add 2 tasks to "build" category: createClassHierarchy and remapFieldNames. They need to be configured,
so add their configuration closures after minecraft closure:
createClassHierarchy{
}
remapFieldNames{
}
In the first closure, you must set pathToSource directory, which contains currently used minecraft and forge source Jars. Example for Linux systems (might work on Windows, too - haven't tested):
createClassHierarchy {
String[] mappingsversion = "$project.minecraft.mappings".split('_')
pathToSource=Paths.get(project.getGradle().getGradleUserHomeDir().toString(), 'caches', 'minecraft', 'net',
'minecraftforge', 'forge', "$project.minecraft.version-$project.minecraft.forgeVersion", mappingsversion[0],
mappingsversion[1]).toFile()
}
In the second closure, set the archive property to your mod Jar, and mcpToSrgMap to the "genSrgs" produced file. Example:
remapFieldNames {
archive=new File(libsDir, project.archivesBaseName + '-' + project.version + '.jar')
setMcpToSrgMap(project.genSrgs.getMcpToSrg().readLines())
}
After refreshing they should be ready to use, but first make sure you have a Groovy source directory created (delete 'java' directory if there is one, it isn't needed) and write some (or much) Groovy code there. Annotate every Groovy file with @CompileStatic.
Building
When you have finished writing and testing your mod, run "build" as always, then run "createClassHierarchy" and "remapFieldNames". createClassHierarchy will make class-to-superclass mappings and class-to-field mappings. remapFieldNames will use these mappings to create a Jar with a classifier "fixed" from the original Jar. You can change the classifier of the produced Jar to something else.
You also should be able to write mixed Java/Groovy code.
To play the mod, the players will just need to get Groovy library from its binaries from official website and put it into 'mods'.
Under the hood
Groovy uses a thingy called 'meta object protocol' which compiles its code differently from Java. We don't want that, because it "hides" class fields from Forge's obfuscation tasks. So we annotate every Groovy file with @CompileStatic, which makes code to compile almost in the same way as Java does. Groovy also sets fields by their names (similarly to getting/setting a field via reflection), not references, thus obfuscation tasks can't find them. This plugin takes care of finding such unobfuscated fields and obfuscates them.
Update, version 0.5: fixed omission of some 'setGroovyObjectProperty' related instructions.