Gradle build system plugin used to automate the setup of a minecraft mod development environment.
MIT License
Bot releases are hidden (Show)
fabricApi.module
Fabric-Jar-Type
manifest entry, either classes
or sources
. Can be used by mod distribution platforms to ensure that the correct jar is uploaded.Failed to verify authentication
error in the console log.Published by modmuss50 over 1 year ago
Published by modmuss50 over 1 year ago
This is mostly a small manintaince release to update the depedencies and fix some bugs.
Published by modmuss50 over 1 year ago
MinecraftJarProcessor
API replacing the deprecated JarProcessor
API.fabric.loom.multiProjectOptimisation
property to opt into complex optimistations for certain projects. This simplifies the logic used in simple projects, removing the prepareRemapJarTask
. You should only enable this option when all of your sub projects share the same Minecraft and mappings versions.Fabric-Loom-Remap
from a dependencies manifest, this allows it to opt-in/out of remapping, even if it does not have a fabric.mod.json file.MinimalExternalModuleDependency
as a FileSpec
input. This allows using version catalogs with layered mappings.Full changelog / diff:
https://github.com/FabricMC/fabric-loom/compare/dev/1.0...dev/1.1
Published by modmuss50 about 2 years ago
--refresh-dependencies
.This update is focused around finalising the split sourceset feature and improving the reliability of loom overall. Loom will now attempt to recover from a previously failed or canceled build. The move to version 1.0 will allow us to better denote any breaking API changes to future loom versions.
Loom 1.0 provides a full suite of tools to build a mod with split common/client code. The previous loom version introduced compile time safety when compiling against Minecraft code. Loom 1.0 expands this to incoming mod dependencies such as Fabric API. Any mod dependency that was also built with this will be split and applied to the correct sourceset, this ensures that you cannot depend on a client only API from your common code.
Please see the updated Loom wiki page with details on how to enable this for your project. https://fabricmc.net/wiki/documentation:fabric_loom
To update please set your loom version to 1.0-SNAPSHOT
at the top of your build.gradle file.
Published by modmuss50 over 2 years ago
See full list of changes here
For years a common source of server crashes has been from mods accidentally calling client only code when installed on a server. Starting with Loom 0.12 and Loader 0.14 an experimental option has been added to require all client code to be moved into its own sourceset. This is done to provide a compile-time guarantee against calling client only Minecraft code on the server. A single jar file that works on both the client and server is built from the two sourcesets.
The following snippet from a build.gradle file shows how you can enable this for your mod. As your mod will now be split across two sourcesets, you will need to use the new DSL to define your mods sourcesets. This enables Fabric Loader to group your mods classpath together. This DSL is also useful for some other complex multi-project setups.
loom {
splitEnvironmentSourceSets()
mods {
modid {
sourceSet sourceSets.main
sourceSet sourceSets.client
}
}
}
This feature has been in development for almost 6 months, requiring major changes to Loom and Loader. Due to the fundamental changes issues are expected, so if you do find an issue please make sure to report it.
Even though this is still an experimental feature Fabric API already makes use of this in the 1.19 branch. There are still some improvements and related features that are planned for future loom versions, that will allow modders to get the most out of this. Meanwhile for more advanced modders that like trying out new things it should be in a good enough state to use.
Published by modmuss50 over 2 years ago
kotlinx.serialization
and issues when depending on kotlin libraries.afterEvaluate
.Interface injection is a compile time only feature, this means that a Mixin should also be used to implement the interface onto the target class. The following snippet can be added to your fabric.mod.json
file to add an interface to the net/minecraft/block/Block
class.
{
"custom": {
"loom:injected_interfaces": {
"net/minecraft/class_2248": ["net/fabricmc/example/ExampleInterface"]
}
}
}
loom {
// Disables client related features and resources.
serverOnlyMinecraftJar()
// Enable runtime only log4j, forces mods to use SLF4J for logging.
runtimeOnlyLog4j = true
}
Loom 0.11 contains major rewrites to a number of core functions to make a lot of these new features possible, if you find any issues please make sure to report them.
Published by modmuss50 almost 3 years ago
namedElements
configuration containg the named jar, helps with multiproject builds (modmuss50)genSourcesWithFernflower
--console plain
arg is used (modmuss50)loom.modVersion
to read the version specified the fabric.mod.json file (modmuss50)The old way of defining maven artifacts to publish has been deprecated in favor of using the java component. This means that this old form:
mavenJava(MavenPublication) {
// add all the jars that should be included when publishing to maven
artifact(remapJar) {
builtBy remapJar
}
artifact(sourcesJar) {
builtBy remapSourcesJar
}
}
Should now be written as:
mavenJava(MavenPublication) {
from components.java
}
This changes now follows the gradle documentation, the old method will continue to work with loom 0.10 but a deprecation warning will be shown. In the rare/complex case where the old method is required loom.disableDeprecatedPomGeneration(publishing.publications.mavenJava)
can be used to supress the deprecation warning, this should only be used if required!
See https://github.com/FabricMC/fabric-example-mod/pull/141/commits/671b3d4526df8ef3ae1a7cd30c4af8c12a35bbb6 as an example of how the example mod was updated.
Due to the above changes some multi-project builds may have broken. Now when you depend on a loom subproject you must specify the namedElements
configuration. This ensures that you are depending on the named "dev" jars, and not the intermediary remapped "production" jars. See as follows:
implementation project(path: ":mySubProject", configuration: "namedElements")
If you are using kotlin for your build script it will be as follows:
implementation(project(":mySubProject", configuration = "namedElements"))
If you need any help with loom 0.10 please don't hesitate to ask in the #mod-dev-gradle-ides channel on Discord.