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.

[LexManos]

Pushed my changes to allow for users to do:

renamerTools {
    configure('mavenizer') {
        version = '2.0' // results in net.minecraftforge:minecraft-mavenizer:2.0
        artifact = 'some.other:tool:1.0' // this will be used before version is, so only specify one.
    }
}

You can still specify the full classpath, which will override all of this, but for the average use case. This is far easier then setting the configurations.

Because the intended use of shared is to be shaded in, I dont think there is a sane way to share the same "tools" extension. So we can set that as a future goal. For now each plugin have its own tools extension is fine.

I have opted to not care about adding a helper for setting the java version:

renamerTools {
    configure('mavenizer') {
        javaVersion = 21
    }
}

the current version is a little verbose but good enough for now:

renamerTools {
    configure('mavenizer') {
        javaLauncher = javaToolchains.launcherFor {
            languageVersion = JavaLanguageVersion.of(21)
        }
    }
}

[Jonathing]

Splitting SimpleModule(Version)Identifier into another project (such as artifact-utils) can be done/discussed at a later time.