3.4 - Shared Tools Rework

[Jonathing]

This PR marks the start of GradleUtils 3.4.0, with the main change being a rework to the Tools system provided by GradleUtils shared. Specifically, the ability to define a tool through it's maven coordinate as opposed to a hard-coded download URL. This also includes an attempt to try and download the tool through Gradle before falling back to trying the Forge Maven (or whatever Maven URL was passed in as the tool's Maven URL).

There are also some additional changes and cleanup to the main plugin, but the main plugin remains binary compatible. As a reminder, binary breaking changes to GradleUtils Shared are fair game no matter the version number, as GradleUtils Shared must always be shadowed and relocated by the consuming plugin.

[LexManos]

My be worth stealing this its tried and tested.

[Jonathing]

artifact-utils :P

[LexManos]

Alright, so quick pass, lots of changes and class shuffleing around but looks fine to me.
To be clear im mainly focused on the usage experience.
Currently we have:
static final Tool MAVENIZER = Tool.of(Constants.MAVENIZER_NAME, Constants.MAVENIZER_VERSION, Constants.MAVENIZER_DL_URL, Constants.MAVENIZER_JAVA_VERSION, Constants.MAVENIZER_MAIN);
I'd prefer something smaller like:
static final Tool MAVENIZER = Tool.ofForge("mavenizer", "net.minecraftforge:mavenizer:1.0:all", JAVA_8); (ofForge tells it to use the forge maven by default for the download)

Also currently we have:

fgtools {
    configure('mavenizer') {
        classpath = configurations.detachedConfiguration(dependencies.create('net.minecraftforge:minecraft-mavenizer:0.4.19'))
    }
}

Preferribly we would be able to do:

fgtools {
    configure('mavenizer') {
        version = '2.0'
        // Ideally this would allow for setting any of the variables, extension, classifier, url, java verion
    }
}

Or, if possible:

fgtools {
    mavenizer.version = '2.0'
}

As 'use the same exact tool, but with a updated version, would be the number one use case.

As for the ToolExec task (this is just reiterating what we've already talk about)
having it find the Main-Class from any executable jar would be nice.

[Jonathing]

having it find the Main-Class from any executable jar would be nice.

While it makes sense on paper, I'm not seeing why this would be necessary. The logic you wrote in MinecraftForge/ForgeAutoRenamingTool#32 makes it look for Main-Class if and only if the classpath only has a single JAR file. This is redundant because Java itself will look for Main-Class if there is only one JAR file run. That is how ToolExec has worked in the past.

[LexManos]

Well you beed to not error when there isnt a main class. And i thought it only looked for a main class when passed in the classpath as -jar not as -cp.
How would java know the first argument is not a classname? Does JavaExec silently translate the two is only one file is specified?

Either way if it works it works.

[Jonathing]

JavaExec silently translates the execution call, yes. See JavaExecSpec#getMainClass.