Hello, folks! I’m going to apologize in advance for (1) not knowing much Gradle and (2) probably doing everything wrong, but I’ve seemingly stumbled into very, very uncharted territory, and could use some help from another set of eyes.
Starting with the basics: we’re doing Minecraft Forge development. Here is a nascent repository I can push to, and here is a module, “UniversalModCore”, I’d like to link into the classpath for the aforementioned root. Following all the examples so far, here’s settings.gradle in our root:
sourceControl {
gitRepository("https://github.com/TeamOpenIndustry/UniversalModCore.git") {
producesModule("cam72cam.universalmodcore:UniversalModCore")
}
}
Unfortunately, as shipped, this config doesn’t work; here’s where things begin to get tricky.
I’m not entirely sure what magic Forge does to accomplish this, but it must be pretty complex; Forge expects you to run the setupDecompWorkspace before even thinking about running the typical build task. In setupDecompWorkspace, it seems to poke into Gradle’s cache the requisite source or binary packages for Forge/MCP itself, so that dependency resolution can find them. (The process of doing so is a long one that involves decompiling an existing jar and applying some transformations that I barely understand myself.) If poking directly into cache sounds abusive to you, you’re in good company, but I’m working with what I’m handed.
Following is a log that is symptomatic of forgetting this crucial step:
grissess@ceres electrical-age-1.12 $ ./gradlew build
> Configure project :
This mapping 'snapshot_20171003' was designed for MC 1.12! Use at your own peril.
> Configure project :UniversalModCore
This mapping 'snapshot_20171003' was designed for MC 1.12! Use at your own peril.
FAILURE: Build failed with an exception.
* What went wrong:
Could not determine the dependencies of task ':UniversalModCore:compileJava'.
> Could not resolve all task dependencies for configuration ':UniversalModCore:forgeGradleMc'.
> Could not find net.minecraftforge:forgeBin:1.12.2-14.23.4.2705.
Searched in the following locations:
- https://minecraft.curseforge.com/api/maven/net/minecraftforge/forgeBin/1.12.2-14.23.4.2705/forgeBin-1.12.2-14.23.4.2705.pom
- https://minecraft.curseforge.com/api/maven/net/minecraftforge/forgeBin/1.12.2-14.23.4.2705/forgeBin-1.12.2-14.23.4.2705.jar
- https://files.minecraftforge.net/maven/net/minecraftforge/forgeBin/1.12.2-14.23.4.2705/forgeBin-1.12.2-14.23.4.2705.pom
- https://files.minecraftforge.net/maven/net/minecraftforge/forgeBin/1.12.2-14.23.4.2705/forgeBin-1.12.2-14.23.4.2705.jar
- https://repo.maven.apache.org/maven2/net/minecraftforge/forgeBin/1.12.2-14.23.4.2705/forgeBin-1.12.2-14.23.4.2705.pom
- https://repo.maven.apache.org/maven2/net/minecraftforge/forgeBin/1.12.2-14.23.4.2705/forgeBin-1.12.2-14.23.4.2705.jar
- https://libraries.minecraft.net/net/minecraftforge/forgeBin/1.12.2-14.23.4.2705/forgeBin-1.12.2-14.23.4.2705.pom
- https://libraries.minecraft.net/net/minecraftforge/forgeBin/1.12.2-14.23.4.2705/forgeBin-1.12.2-14.23.4.2705.jar
- file:/home/grissess/.gradle/caches/minecraft/deobfedDeps/net/minecraftforge/forgeBin/1.12.2-14.23.4.2705/forgeBin-1.12.2-14.23.4.2705.pom
- file:/home/grissess/.gradle/caches/minecraft/deobfedDeps/net/minecraftforge/forgeBin/1.12.2-14.23.4.2705/forgeBin-1.12.2-14.23.4.2705.jar
- file:/home/grissess/.gradle/caches/minecraft/net/minecraftforge/forge/1.12.2-14.23.4.2705/snapshot/20171003/forgeBin-1.12.2-14.23.4.2705.jar
- file:/home/grissess/.gradle/caches/minecraft/net/minecraftforge/forge/1.12.2-14.23.4.2705/snapshot/20171003/forgeBin.jar
Required by:
project :UniversalModCore
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
* Get more help at https://help.gradle.org
BUILD FAILED in 6s
What should happen is forgeBin-1.12.2-14.23.4.2705.jar getting generated (and cached) by UniversalModCore's setupDecompWorkspace, but that hasn’t been run yet. Actually, everything builds if I step manually into .gradle/vcs-1/UniversalM_48vdk4o6cou385w0ytu9jfyiv/UniversalModCore/ and run the setupDecompWorkspace task there, but that’s hardly turn-key for our developers, not to mention CI tasks.
Unfortunately, because this comes in as a source repository, I’m having a hard time declaring a dependency on the project. Something as simple as
setupDecompWorkspace.dependsOn ":UniversalModCore:setupDecompWorkspace"
fails with this issue:
grissess@ceres electrical-age-1.12 $ ./gradlew setupDecompWorkspace
> Configure project :
This mapping 'snapshot_20171003' was designed for MC 1.12! Use at your own peril.
FAILURE: Build failed with an exception.
* What went wrong:
Could not determine the dependencies of task ':setupDecompWorkspace'.
> Task with path ':UniversalModCore:setupDecompWorkspace' not found in root project 'electrical-age-1.12'.
As can be seen, the source project is not yet configured–indeed, lacking this line, :UniversalModCore is never configured for the root project’s setupDecompWorkspace task, which I was able to (doubly) confirm by asking Gradle to print the projects it knew about in a doLast block for that task (the answer was one: the root project).
Trying to add the dependency for the build task also fails; as can be seen in the first log above, UniversalModCore throws an error during project configuration because of that missing dependency, which means I can’t hook any event that waits until after all projects are configured (and thus all tasks loaded). I honestly have no idea how setupDecompWorkspace itself manages to sidestep this missing dependency during configuration, and that’s probably a key insight I’m missing.
As it stands, everything (aside from having to manually run a task in the VCS directory) works, including the build task once that is done, and even IDE integration. This appears to be the last issue in the way. I’m not adverse to:
- Bothering upstream to poke something into their
build.gradle, if modifying ours is insufficient, but they already have their own build chain decided upon (and it abjectly avoids gradle by dropping into Bash scripts); - Declaring this relation in another way (although git submodules, e.g., are a bit annoying–I always forget
--recursive) - Anything else you can think of, really; this just seemed convenient at the time.
Any help is greatly appreciated!