-
-
Notifications
You must be signed in to change notification settings - Fork 18
Implementation Details
Applies to VanillaGradle 0.2 and up
These are some notes about the internals of VanillaGradle, to help in understanding how it works. They are subject to change at any time.
Because Minecraft is not published in a standard repository format, VanillaGradle has to populate its own metadata for Minecraft jars.
When the VanillaGradle plugin is applied, Minecraft is presented as a standard Maven artifact.
Group ID: net.minecraft
Artifact ID: client, joined, or server, depending on the distribution desired. Internally, this may be modified to append a series of artifact modifier tags. These are in the form of [_<key>-<stateKey>]*, to disambiguate different artifact transformations, such as access wideners or alternate mappings.
Version: A specific release. Dynamic versions should be supported, but Gradle limitations means that their support is limited.
The joined artifact provides both client and server capabilities. This means that any dependency on a project that requests a joined distribution will mean the downstream project receives a joined distribution.
Caution: This information is provided for reference only and is subject to change at any time
Internally, VanillaGradle uses two Ivy repositories to hold processed Minecraft artifacts.
These are:
| Repository name | Purpose | Disk location |
|---|---|---|
| VanillaGradle Global Cache | Standard shared resources (remapped jars, downloaded mappings, etc) | $GRADLE_HOME/caches/VanillaGradle/v1/ |
| VanillaGradle Project Cache | Access-widened jars | ${project.rootDir}/.gradle/.caches/VanillaGradle/v1/ |
When a configuration is resolved, the appropriate Minecraft jar is produced based on the requested dependency.
The extension points provided in an Ivy repository are used to inject the appropriate metadata -- which versions are available, their dependencies, and extra attributes such as JVM version and active mapping set.
In order to provide artifacts to Gradle, VanillaGradle needs to hook into configuration resolution to generate the appropriately mapped artifact.
These hooks are all executed before Gradle actually reads the files on disk, providing a workable opportunity to generate mapped artifacts on demand.
These hooks are associated with the repository definition, which can be applied to either the main buildscript or the settings central repository declarations:
- version lister, which passes available versions from the Mojang manifest through
- metadata supplier, used for dynamic version resolving. This metadata supplier will generate artifacts for any version where metadata is queried
-
ResolutionStrategy.eachDependency-- used for non-dynamic MC versions, plus priming the resolver with the project context needed to resolve in the metadata supplier