Add Gradle Plugin

[LexManos]

First pass at making a gradle plugin.
This is functional. See the demo for the examples.
Need to speak with @Jonathing about a lot of the implementation.

I did not use ToolExecBase because I have a few issues with it.
Namely, the Tool object is very clunky to work with.
It doesn't auto-detect main classes.
It doesn't support maven coordinates, or downloading the tools from configured repositories.

My implementation in theory (gradle didn't yell at me) is compatible with the config cache.
It uses detached configurations to download the mappings and tool.

So a basic overview:

plugins {
  id 'net.minecraftforge.renamer'
}

renamer {
  mappings(channel, version) // Shorthand for mappings('net.minecraft:mappings_channel:[email protected]')
  mappings(string) // Shorthand for mappings(dependencies.create(string))
  mappings(Dependency) // Will use this dependency as the mapping file for subsequent calls to renamer.rename(task)
}

// Creates a 'jarRename' task using the compileClasspath
// input is set to task.archiveFile
// output is set to a renamed task.archiveFile (adding -renamed before the extension)
// map is set from the previous call to renamer.mappings (or null if unset)
// tool is set to `net.minecraftforge:ForgeAutoRenamingTool:1.1.2:all`
// args is set to "--input", "{input}", "--output", "{output}", "--map", "{map}", "--lib={library}"
// javaLauncher is set to javaToolchains.launcherFor(java.toolchain)
// Shorthand for renamer.rename(jar, jar.name + 'Rename', null)
renamer.rename(jar)

// It also support specifying a closure
renamer.rename(jar) {
  map = file('map.tsrg')
}

// Or configuring the task itself
tasks.named('jarRename') {
  map = file('map.tsrg')
}

I have not done anything to mark the task as an artifact/publish.

[LexManos]

Okay so skimming over your changes.
What is the 'name' passed in to the extension methods, it just seems to be the task name prefix.
Fundamental question, why is this centered so much around source sets?
Often times in modders setups there are multiple sourcesets being used in the same final jar task.

Super stupid question, everything seems to boil down to trying to get the specified configurations.
f3d444e#diff-e31b13a27a3c3d29f51fc7f589c02bb66bc8886343f1bed3443a56ebb263749dR68

And trying to get a task that can be passed to artifact
Which is anything that is possible to passed into the NotationParser
Which supports anything that extends PublishArtifact which is Public API
We can do something similar to what Gradle does for AbstractArchiveTask. Just redirecting getFile and builtBy

As for the DSL. As discussed on discord, ideally the normal user would just do renamer.enable() which would basically do something like:

renamer.classes(jar) // Makes a renameJar task and configures these defaults

tasks.named('renameJar') {
  dependsOn jar
  input = jar.getArchiveFile
  output = file("libs/$archiveBaseName-$version-renamed.jar")
  map = renamer.mappings
  classifier = 'renamed'
  libararies = sourcesets.main.compileClasspath
}

configurations {
  renamed
}

artifacts {
  renamed new RenamedArtifact(renameJar, jar) // The wrapper for PublishArtifact like I mentioned above
}

I'm not sure how to add variants to the publish with the correct attributes. But this could be a different/easier approach.
One that doesnt tie our hands to the AbstractArchiveTask

[LexManos]

Note to self: Need to just use the full normal gradle wrapper cuz intellij is dumb

[LexManos]

Is this delayed until the task is executed so that the value is valid?

[LexManos]

Somewhat related question, is it possible to have a shared 'tools' extension so that modders can configure things in one place? Yes I know this means we will have to coordinate the names across all the plugins, but that shouldnt be an issue.

[LexManos]

Does this variant still include the 4MB of font files?