fabricmc/fabric-loom

Gradle build system plugin used to automate the setup of a minecraft mod development environment.

Fabric Loom

A Gradle plugin to setup a deobfuscated development environment for Minecraft mods. Primarily used in the Fabric toolchain.

• Has built in support for tiny mappings (Used by Yarn)
• Utilises the Fernflower and CFR decompilers to generate source code with comments.
• Designed to support modern versions of Minecraft (Tested with 1.14.4 and upwards)
• Built in support for IntelliJ IDEA, Eclipse and Visual Studio Code to generate run configurations for Minecraft.
• Loom targets the latest version of Gradle 7 or newer
• Supports Java 16 upwards

Use Loom to develop mods

To get started developing your own mods please follow the guide on Setting up a mod development environment.

Debugging Loom (Only needed if you want to work on Loom itself)

This guide assumes you are using IntelliJ IDEA, other IDE's have not been tested; your experience may vary.

1. Import as a Gradle project by opening the build.gradle
2. Create a Gradle run configuration to run the following tasks build publishToMavenLocal -x test. This will build Loom and publish to a local maven repo without running the test suite. You can run it now.
3. Prepare a project for using the local version of Loom:
   • A good starting point is to clone the fabric-example-mod into your working directory
   • Add mavenLocal() to the repositories:
     • If you're using id 'fabric-loom' inside plugins, the correct repositories block is inside pluginManagement in settings.gradle
     • If you're using apply plugin: for Loom, the correct repositories block is inside buildscript in build.gradle
   • Change the loom version to 0.6.local. For example id 'fabric-loom' version '0.6.local'
4. Create a Gradle run configuration:
   • Set the Gradle project path to the project you have just configured above
   • Set some tasks to run, such as clean build you can change these to suit your needs.
   • Add the run configuration you created earlier to the "Before Launch" section to rebuild loom each time you debug
5. You should now be able to run the configuration in debug mode, with working breakpoints.

fabric-loom's Issues

[0.3.0] genIdeaRuns should create the run dir

Idea will fail to launch a run config with an invalid run dir, loom should auto create this when generating the run configs.

LoomFernflowerDecompiler should not copy non-source files.

Importing the Gradle project in IDEA causes issues with finding Launchwrapper

From quat:

When I enable the Gradle tool window, that's when it starts breaking due to being unable to find launchwrapper.
Like, IDEA pops up "Unlined gradle project? Import Gradle project!", I press ok to make it shut up and also since it's a forgegradle habit, and that's when the run configuration stops working.```

Mapped and unmapped versions of Fabric and Fabric loader being added to dependencies.

This behavior strangely only occurs for these two jars and no other jars that have mappings applied to them. The issues caused as a result are pretty sporadic.

dependency on other mod requires additional runtime dependency

modCompile(group = "net.fabricmc", name = "fabric-language-kotlin", version = Fabric.LanguageKotlin.version)
runtime(group = "net.fabricmc", name = "fabric-language-kotlin", version = Fabric.LanguageKotlin.version)

runtime is currently required so that libraries bundled in fabric-language-kotlin are detected and the runClient / runServer tasks do not fail

maybe there is a better configuration to use (compileOnly also seems to work) but this worked well for me,

without it the bundled coroutines library is not added as dependency properly for example

Mixin library won't write refmap entries if they don't involve any remapping

Sounds rational, right?

Well... what if we have something intermediary-named, such as "method_3800", and it's not mapped yet - so there's no named->intermediary remap going on, and as such a refmap entry doesn't get written even though it should.

We need to patch sponge-mixin to allow overriding this behaviour and allowing remapping of any descriptor which touches classes in net/minecraft/.

Add Eclipse support

[Suggestion] allow setting the run directory in the buildscript

it'd really be nice to allow setting the run directory from within the buildscript, like forgegradle does

Compilation of a TagEntry mixin fails

Compiling a project with @Mixin(net.minecraft.world.loot.entry.TagEntry.class) fails.

class net.minecraft.world.loot.entry.LootEntry cannot access its superinterface net.minecraft.world.loot.LootChoiceProvider

A possible cause is that LootChoiceProvider is package-private and the entry types are placed into a separate package in Yarn. Compiling and running the game in IDEA works just fine. I'm not using the LootEntry type directly, just the TagEntry subclass.

Log: https://gist.github.com/Juuxel/80c2df93e5d0fab417c0b35ca6979e22

IDEA run configuration generation uses wrong default for 'shorten command line'

When I was on windows and generated an IDEA project using 'gradlew genSources idea' the run configuration used a command line shortening method that makes the mod not load. The configuration was set too:

Shorten command line: 'user-local default: JAR manifest'

I had to set it to 'none' to have a working loading mod

Versions:

minecraft "com.mojang:minecraft:18w49a"
mappings "net.fabricmc:yarn:18w49a.10"
modCompile "net.fabricmc:fabric-loader:0.2.0.64"
modCompile "net.fabricmc:fabric:0.1.0.37"

runClient injects *all* JARs from build/libs into the classpath, not just outputs

how to exclude dependencies provided by other mods

my usecase is:
fabric-language-kotlin bundles

• kotlin-stdlib
• kotlin-reflect
• kotlinx-coroutines-core

my mod matterlink additionally depends on

• Fuel
• Fuel-coroutines
• Fuel-serialization

which in turn depend on

• kotlinx-serialization-runtime
• Result (dependency of Fuel)
• kotlin-stdlib (already provided by fabric-language-kotlin)
• kotlin-reflect (already provided by fabric-language-kotlin)
• kotlinx-coroutines-core (already provided by fabric-language-kotlin)

now i need to bundle these Fuel libraries, but there seem to be no way to exclude the already provided libraries from configurations

how can i exclude all provided dependencies from mods added via modCompile from other configurations (eg. shadow) ?

modCompile does not resolve dynamic versions

in version 0.1.0-SNAPSHOT the following was working:
modCompile(...., version = "1.3.10+")

to get always the latest buildnumber from maven
and loom would resolve the versions and use the resolved configuration for anything it needed

now it tried to look up the remapped jar file with the dynamic version in the filename

fabric-loom randomly refuses to auto-attach "refmap" entries

Changing your mappings prevents you from going back to a previous version of the mappings that you have used

Essentially, if you were to update to the latest mappings version and then go back to the previous version, for example, attempting to do so will throw an error saying that the jar file for the previous mappings cannot be deleted because it is in use by another program.

FileSystemAlreadyExists when building in CircleCI

I'm getting FileSystemAlreadyExists exception from tiny-remapper when building a mod (sargunv/always-drop-loot) in CircleCI. From discussion in FabricMC/tiny-remapper#7, it sounds like loom is not releasing a file. Could be related to #45.

I can reproduce the issue every time I build in the CircleCI environment. Perhaps building inside a docker container from their image (circleci/openjdk:8-jdk) would reproduce it.

Here's a sample stack trace of the crash from tiny-remapper: https://pastebin.com/5MjxLqfd

Fernflower can't decompile TagEntry

While upgrading to 19w14b.9 i faced the issue that loom couldn't decompile net/minecraft/world/loot/entry/TagEntry. This happens with the following mappings:

• 19w14b.9
• 1.14 Pre-Release 1+build.1
• 1.14 Pre-Release 1+build.2
• 1.14 Pre-Release 1+build.3

Additional information

Gradle.log
Project

Importing a loom Gradle project into IDEA and running genSources from IDEA does not work

IDEA won't use the generated sources, it will still decompile the .class files itself, which results in mismatched line-numbers.

Rework genSources behaviour

• ideaSources, vscodeSources, eclipseSources -> idea/vscode/eclipse + genSources
• genSources should only generate sources if not present
• regenSources to actually force-regenerate sources

modCompile does not add to compile

output of dependencies: https://gist.github.com/NikkyAI/5d209104e3b2883322082a4f497d918b

with these dependnecies:

dependencies {
    minecraft(group = "com.mojang", name = "minecraft", version = Minecraft.version)

    mappings(group = "net.fabricmc", name = "yarn", version = "${Minecraft.version}.${Fabric.Yarn.version}")

    modCompile(group = "net.fabricmc", name = "fabric-loader", version = Fabric.version)

    modCompile(group = "net.fabricmc", name = "fabric-language-kotlin", version = Fabric.LanguageKotlin.version)

    modCompile(group = "net.fabricmc", name = "fabric", version = Fabric.FabricAPI.version + ".+")

    api(
        group = "org.jetbrains.kotlinx",
        name = "kotlinx-serialization-runtime",
        version = KotlinX.Serialization.version
    )
    shadow(
        group = "org.jetbrains.kotlinx",
        name = "kotlinx-serialization-runtime",
        version = KotlinX.Serialization.version
    ) {
        isTransitive = false
    }

    api(group = "com.github.kittinunf.Fuel", name = "fuel", version = Fuel.version)
    shadow(group = "com.github.kittinunf.Fuel", name = "fuel", version = Fuel.version) {
        isTransitive = false
    }
    api(group = "com.github.kittinunf.Fuel", name = "fuel-coroutines", version = Fuel.version)
    shadow(group = "com.github.kittinunf.Fuel", name = "fuel-coroutines", version = Fuel.version) {
        isTransitive = false
    }
    api(group = "com.github.kittinunf.Fuel", name = "fuel-kotlinx-serialization", version = Fuel.version)
    shadow(group = "com.github.kittinunf.Fuel", name = "fuel-kotlinx-serialization", version = Fuel.version) {
        isTransitive = false
    }

    api(group = "com.github.kittinunf.result", name = "result", version = "2.0.0")
    shadow(group = "com.github.kittinunf.result", name = "result", version = "2.0.0") {
        isTransitive = false
    }

    api(group = "blue.endless", name = "jankson", version = "1.0.0-7")
    shadow(group = "blue.endless", name = "jankson", version = "1.0.0-7") {
        isTransitive = false
    }
}

fabric-language-kotlin does not even appear in the dependnecies list ?
there is no modCompile section at all (i remember there was one before)

furthermore there seems to be no good way for me to look at which dependnecies fabric-language-kotlin bundles and exclude them from shadowjar (even if i add it to runtimeOnly)

probably related to #32

Automatically set refmap name in mixin JSONs

We already have facilities to scan for mixin JSONs in a JAR - we use them to remap refmaps in imported mods. Use that to set refmap filenames on compiled mods based on Gradle script to save some user headaches.

Using mod* configurations with a flatDir repository does not deobfuscate

When modCompile is used to depend on a JAR from a flatDir repository, the dependency is not deobfuscated from intermediary names.

For example, if I remove the -dev classifier of a JAR dependency in my build.gradle.kts, this happens:

Support dependency remapping with more configurations

The dependency management page for the Java Plugin explains how configurations should probably be dealt with.

The Java Library Plugin adds a few more configurations as well.

A possible use case is for mods exposing an API with separate API and implementation artifacts. The API would be depended on as compileOnly and the implementation as runtimeOnly

First of all, compile has been deprecated. At minimum we might want to deprecate modCompile and introduce modImplementation, but more ideally I think remapping should work with any configuration. This has been shown to work in practice in ForgeGradle.

Eclipse support

😞 - but many people would probably like to have it.

Depends on #15

debof

https://github.com/FabricMC/fabric-loom/search?q=debof

Typo?

modCompile files("...") tries to find "null:unspecified:null"

When trying to add a local .jar file via modCompile files("...") gives the following error:

Could not resolve all files for configuration ':compileClasspath'.
> Could not find null:unspecified:null.mapped.yarn.2.

( might be related to #26 )

compile output log.txt

Add VSCode support

• javac based language plugin
• java-language-server language plugin using Eclipse JDT
• Debugger support plugin

enable stitch snowmen removal as some IDEs don't rename LVTs automatically

[0.3.0] Building example mod fails due to missing mixin target.

https://gist.github.com/modmuss50/39b4344f691373ead343ebca6d4e277e

relevant build.gradle parts:

minecraft {
	version = project.minecraft_version
	mappings = "net.fabricmc:yarn:${project.yarn_mappings}"
}

dependencies {
	//to change the versions see the gradle.properties file
	modCompile "net.fabricmc:fabric-loader:${project.loader_version}"

	// Fabric API. This is technically optional, but you probably want it anyway.
	modCompile "net.fabricmc:fabric:${project.fabric_version}"
}

FabricAPI is missing minVersion definitions in its mixin configs?

Supposedly fabric-loom is the place for this since it's what patches the JSONs.

Minor, ignorable, annoying. (Occurs in the example mod as well.)

[05:37:29] [main/ERROR]: Mixin config fabric-loader.mixins.common.json does not specify "minVersion" property
[05:37:29] [main/ERROR]: Mixin config fabric-loader.mixins.client.json does not specify "minVersion" property
[05:37:29] [main/ERROR]: Mixin config net.fabricmc.fabric.mixins.common.json does not specify "minVersion" property
[05:37:29] [main/ERROR]: Mixin config net.fabricmc.fabric.mixins.client.json does not specify "minVersion" property

gradle 5.0 does not generate refmaps

logs using gradle 4.10.2 and 5.0: https://gist.github.com/NikkyAI/4179692344ca78625419d7ba626d7b03

the biggest difference is that from the compileJava step huge chunks are missing

Note: SpongePowered MIXIN Annotation Processor Version=0.7.11
Note: ObfuscationServiceFabric supports type: "official:intermediary"
Note: ObfuscationServiceFabric supports type: "official:named"
Note: ObfuscationServiceFabric supports type: "intermediary:official"
Note: ObfuscationServiceFabric supports type: "intermediary:named"
Note: ObfuscationServiceFabric supports type: "named:official"
Note: ObfuscationServiceFabric supports type: "named:intermediary"
Note: ObfuscationServiceMCP supports type: "searge"
Note: ObfuscationServiceMCP supports type: "notch"
Note: Loading named:intermediary mappings from /home/nikky/.gradle/caches/fabric-loom/mappings/yarn-tiny-18w50a.26
Note: Writing refmap to /home/nikky/dev/fabric/fabric-example-mod-kotlin/build/classes/java/main/kotlin-example-refmap.json
Note: Writing refmap to /home/nikky/dev/fabric/fabric-example-mod-kotlin/build/classes/java/main/kotlin-example-refmap.json
Note: Writing named:intermediary output TinyMappings to /home/nikky/dev/fabric/fabric-example-mod-kotlin/.gradle/minecraft/mixin-map-18w50a.26.tiny
Note: Writing refmap to /home/nikky/dev/fabric/fabric-example-mod-kotlin/build/classes/java/main/kotlin-example-refmap.json
Note: Writing refmap to /home/nikky/dev/fabric/fabric-example-mod-kotlin/build/classes/java/main/kotlin-example-refmap.json
Note: Writing named:intermediary output TinyMappings to /home/nikky/dev/fabric/fabric-example-mod-kotlin/.gradle/minecraft/mixin-map-18w50a.26.tiny

apart fro mthat it works fine in the dev env using runClient/runServer and just fails silently on remapJar

NPE in runClient in multi-project setup

Could not find refmap definition, will be using default name: multi-mod-core-refmap.json

> Task :featureA:remapJar
Source .JAR not found!

> Task :featureA:build
> Task :featureA:buildNeeded
> Task :featureA:runClient FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':featureA:runClient'.
> java.lang.NullPointerException (no error message)

* Try:
Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Exception is:
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':featureA:runClient'.
	at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:49)
...
Caused by: java.lang.NullPointerException
	at net.fabricmc.loom.util.RunConfig.clientRunConfig(RunConfig.java:154)
	at net.fabricmc.loom.task.RunTaskBase.getJvmArgs(RunTaskBase.java:128)

Source .JAR not found! is worrying me a little

apart from that it seems to throw a NPE when getting the jvmArguments because this line throws a NPE config = configProvider.apply(getProject());
it seems like either configProvider is null or the tasks getProject() somehow fails

it seems like other loom tasks fail the same in subprojects, like cleanLoomBinaries

a project to reproduce: https://github.com/DaemonicLabs/multi-mod

Use mappings/mappings.tiny-in-classpath on dev environments

This would allow us to remove the --fabricMappingFile codepath.

included dependencies are not exposed

when i include dependencies, into a mod and then depend on that subproject from another one, all code that should be available (and is not marked as error in idea) errors during compile step in gradle

i think the problem is that modCompile has to transitively add all included mods and libraries

one possible workaround is to make remapJar depends on targetProject.tasks.publishTomavenLocal
and making sure all dependencies from include are added as runtime scope
but this is just a ugly quickfix

Multi-project setups fail to build

Using subprojects works fine for developing, however a few things go wrong when building.
Specifically, when compiling subprojects, loom fails to find some variables like its own version.

My project: https://github.com/Ladysnake/Satin/tree/87e2e3b1e976ff10302d50edf79a82b4b688b47f
I have a root project, and test mods setup as subprojects that depend on the root project.
Here is the output of the gradle build command:
https://gist.github.com/Pyrofab/d499b4a1a1ee8e05b14b91cc330db73f

Even if I provide a fabric-loom-null.jar artifact, a second issue pops up when a subproject depends on another via the modCompile configuration, where loom searches for the artifact in the repositories rather than the build output.

[0.3] Lets talk abstracting loom away from Minecraft

Some of you may have heard that I've been working to port Loom over to StarMade. One key component is loom as it download's the appropriate mappings, sets up Mixin Annotations during the compile task, etc...

The request for loom to be more abstract is sparked from fabric-loader 0.4 becoming less specific to Minecraft in terms of loading mods. As it's successfully been used used to load mods into StartMade.

Asset/Libraries

• Minecraft
  • A Version Manifest JSON file to get all versions of the game
  • A version JSON file that lists
    • All libraries
    • Downlaods (client,server)
    • And link to Asset index
  • Asset indedx lists each assets' name, hash and size.
• StarMade
  • Has a releaseIndex that can be treated as a manifest.
    • Not formally formatted (space and # seperated version,date and base download URL)
    • Example: (http://files.star-made.org/releasebuildindex)

      0.201.363#20190214_171006 ./build/starmade-build_20190214_171006
      0.201.364#20190219_163910 ./build/starmade-build_20190219_163910
      0.201.370#20190316_235125 ./build/starmade-build_20190316_235125
      

  • The version index is another space seperated file that lists all downloads,libraries and assets with to classifier.
    • Example: (http://files-origin.star-made.org/build/starmade-build_20190316_235125/checksums)

      ./lib/transaction-api-1.1.jar 15071 2ca09f0b36ca7d71b762e14ea2ff09d5eac57558
      ./lib/tempus-fugit-1.1.jar 55953 4f47af53091985a3e3581af60e432a556a69e2cd
      ./CrashAndBugReport.jar 54344 2f5850c6e10970a478a04b132fcf0584541ae2da
      ./version.txt 25 90b3e489aa4a88194c40cd3c917b5086521af02b
      ./third-party/SoundSystem LibraryJavaSound License.txt 1169 a1cf8b235cbd396c250b9f0908d3630c4ea2e616
      ./StarMade.jar 11231897 391336baf73722ca87336278a2ccfb40b414b3bd
      

With AssetIndexJson, VertsionInfoJson and VersionManifestJson classes, i've added a static method to parse the above and add entries based on file type. However this is isn't the best approach for the long term.

Merging Jars

StarMade only has a single game jar that provides both Server and Client modes. At the same time if playing singleplay or hosting a multiplayer lan.

I've removed the merge jars task in the fork of loom for StarMade, but this could be made an optional step.

The Loom extension minecraft

This could be renamed to just loom when used in the build.gradle script.

minecraft { // This can be renamed to loom. And have another field to quickly select a minecraft configuration.
	version = project.minecraft_version
	mappings "net.fabricmc:yarn:${project.yarn_mappings}"
}

Unless it's possible to configure multiple gradle extensions, one per supported game that sets up (enables/disables) tasks in the loom plugion.

---

These are my thoughts so far and I welcome any feedback on ways to move forward or if it's better to maintain a fork and merging changes from upstream.

Rebuilding Yarn in local repo does not cause rebuilt minecraft.jar

When yarn is built outside of the usual CI system and installed in the local Maven repo, its jar is assigned a name like "yarn-18w50a-local.jar". This name does not change if yarn is rebuilt and installed again. Thus, after rebuilding yarn a second time, the changes are not detected when a mod (that is configured to fetch yarn from the local repo) is built with --refresh-dependencies, and so the minecraft-18w50a-mapped-local.jar is not rebuilt with the new mappings. To force a proper rebuild, both the mapped jar and the mappings must be removed from the cache folder.

The loom mechanisms (MinecraftMappedProvider, MappingsProvider, et al) for extracting the mappings from the yarn jar and rebuilding the mapped minecraft jar using those mappings only rely on the version numbers (or rather, filenames) of the mappings and the minecraft jar to decide whether to rebuild the mapped minecraft jar.

Optionally decompile JAR with JetBrains FernFlower

run directory is in the rootProject directory and other small issues

when using loom in a subproject and executing runClient the run directory is in the rootProject not the subProject

and 2 other problems i encountered over the last few days, if necessary i can split them into seperate issues

no version printed in subprojects

also it does not print the version anymore, which can be annoying when you expect it to there and try to figure out whats wrong

fails to provide in multi project

also another more annoying bug was encountered adding a test mod as subProject to the kotlin module

the test mod depends on the shadowJar output of the main project
now :remapping fabric-language-kotlin-1.3.21+local.jar (TinyRemapper, intermediary -> named) happens before the first task can run
it also happens before shadowJar can run to create the jar it tries to remap
and it fails to provide until you exclude the subproject, run shadowJar and hope it works this time

[0.3.0] Could not find net.fabricmc.yarn.19w11b-9.net.fabricmc:fabric-loader:0.3.7.109.

log: https://gist.github.com/NikkyAI/b079732fa19dda6bb2012063cb753abc

apparently dependnecies are getting accessed too early?

Detect and Report Unsupported JVM

Would be super handy if this reported when you used an unsupported JVM instead of just failing with a vague error.

Example error:

$ ./gradlew genSources idea
Downloading https://services.gradle.org/distributions/gradle-4.10.2-bin.zip
.................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
Unzipping /home/gudenau/.gradle/wrapper/dists/gradle-4.10.2-bin/cghg6c4gf4vkiutgsab8yrnwv/gradle-4.10.2-bin.zip to /home/gudenau/.gradle/wrapper/dists/gradle-4.10.2-bin/cghg6c4gf4vkiutgsab8yrnwv
Set executable permissions for: /home/gudenau/.gradle/wrapper/dists/gradle-4.10.2-bin/cghg6c4gf4vkiutgsab8yrnwv/gradle-4.10.2/bin/gradle

Welcome to Gradle 4.10.2!

Here are the highlights of this release:
 - Incremental Java compilation by default
 - Periodic Gradle caches cleanup
 - Gradle Kotlin DSL 1.0-RC6
 - Nested included builds
 - SNAPSHOT plugin versions in the `plugins {}` block

For more details see https://docs.gradle.org/4.10.2/release-notes.html

Starting a Gradle Daemon (subsequent builds will be faster)

FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring root project 'TestMod'.
> Could not resolve all artifacts for configuration ':classpath'.
   > Could not resolve net.fabricmc:fabric-loom:0.1.0-SNAPSHOT.
     Required by:
         project : > fabric-loom:fabric-loom.gradle.plugin:0.1.0-SNAPSHOT:20181219.230650-15
      > Could not resolve net.fabricmc:fabric-loom:0.1.0-SNAPSHOT.
         > Unable to load Maven meta-data from http://maven.fabricmc.net/net/fabricmc/fabric-loom/0.1.0-SNAPSHOT/maven-metadata.xml.
            > Could not get resource 'http://maven.fabricmc.net/net/fabricmc/fabric-loom/0.1.0-SNAPSHOT/maven-metadata.xml'.
               > Could not GET 'http://maven.fabricmc.net/net/fabricmc/fabric-loom/0.1.0-SNAPSHOT/maven-metadata.xml'.
                  > Received fatal alert: handshake_failure

* 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 12s

Task 'setupFabric' not found in root project 'fabric-loom'.

Either the readme is wrong or build.gradle is wrong.

Updating minecraft version without updating the mappings creates broken mapped jar file which breaks later mappings with the same build number

Updating from 18w49a to 18w50a created this empty jar file, minecraft-18w50a-mapped-20.jar (20 probably because I used the 18w49a.20 mappings before), which made me have to delete this file to regenerate it correctly when the "real" 18w50a.20 mappings were released. Note the last modified date of 12/12 which is the same as the merged jar's, but before the mapped-15 jar.

maven-publish: using loom, components.java exposes way too many dependencies

Currently, just dropping maven-publish into a fabric gradle project creates a crazed pom with literally every dependency of minecraft, plus fabric, plus every modCompile. The input to maven-publish is usually components.java, and that is generally the only component that ever exists.

Right now there's a workaround involving going into the xml and literally deleting the dependencies node, but this.... isn't ideal.

Use More Threads

During the setup process gradle starts up four worker threads, often times only one is doing any actual work. Would be nice if the load was distributed for multi-threaded systems to decrease build times.

tasks runClient and runServer use old launchwrapper classes

./gradlew runClient fails with

Error: Could not find or load main class net.minecraft.launchwrapper.Launch

similar with the runServer task

[0.3.0] there are no gradle run tasks

i am not able to find the gradle tasks runClient and runServer
the generate idea runconfigs are not working, they do not call the mod initalizer

the idea run configs never actually worked for me as well as the gradle run tasks

and without gradle tasks using the pricessResources tasks to modify fabric.mod.json for replacing the modid or version numbers is very unintuitive

0.2.0 does not support paths with spaces

https://pastebin.com/DHTpLeKu

0.1.0 is quite happy with this path and project.

FileSystemException's are back

https://gist.github.com/modmuss50/67e55a17b7e2093aabbd264ef8db6cea

D:\Games\Minecraft\fabric\Assembly\.gradle\minecraft\remapped_mods\SilkAPI-1.0.0-25.mapped.yarn.64.jar: The process cannot access the file because it is being used by another process.

Seems to be quite reproducible, by just re-running gradle again, I can look when I get a chance

modCompile files("...") will not save remapped class files

Only seems to happen with local files.