Gradle And Project Layout

This page explains each build file in the plugin template. SoulFire plugins use a Fabric Loom project with SoulFire dependencies and resources.

Published coordinatesCopy Anchor Link

SoulFire publishes plugin dependencies under the com.soulfiremc group:

Use the metadata for the exact backend release you target. The template can lag behind the runtime. Compare its complete dependency set with the matching SoulFire source. The shared coordinate appears in the older template. Do not assume that every newer runtime publishes the same module layout. The current source keeps shared Java classes inside its existing modules. Use the source build's publishing tasks and dependencies for that baseline.

External references for this pageCopy Anchor Link

• Fabric Documentation
• Fabric wiki: Access wideners
• SpongePowered Mixin wiki

Minimal repositories blockCopy Anchor Link

These repositories provide the required dependencies:

repositories {
  maven("https://repo.codemc.org/repository/maven-public/")
  maven("https://maven.fabricmc.net")
  maven("https://libraries.minecraft.net")
  mavenCentral()
}

The official template contains additional repositories for transitive dependencies. If you are unsure, copy the complete block from the template.

Minimal dependency shapeCopy Anchor Link

The core structure looks like this:

dependencies {
  minecraft("com.mojang:minecraft:<minecraft-version>")
  implementation("net.fabricmc:fabric-loader:<fabric-loader-version>")

  implementation("com.soulfiremc:mod:<soulfire-version>")
  compileOnly("com.soulfiremc:shared:<soulfire-version>")

  compileOnly("org.projectlombok:lombok:<lombok-version>")
  annotationProcessor("org.projectlombok:lombok:<lombok-version>")
}

Use implementation for com.soulfiremc:mod because your plugin uses this API while SoulFire runs. Use compileOnly for shared unless you know you need it packaged differently.

Loom configurationCopy Anchor Link

The example plugin uses this pattern:

loom {
  accessWidenerPath = file("src/main/resources/my-plugin.accesswidener")

  runs {
    removeIf { true }
  }
}

That means:

• your plugin can ship an access widener if needed
• the template disables Loom run configurations because the plugin is not a standalone game or server

Test the plugin against a real SoulFire install instead of expecting the plugin project itself to boot SoulFire.

Recommended file layoutCopy Anchor Link

fabric.mod.jsonCopy Anchor Link

At minimum, your metadata file needs:

• a unique id
• a main entrypoint
• a SoulFire dependency entry under depends
• your mixin config name if you use Mixins
• your access widener name if you use one

The official example uses this dependency block:

"depends": {
  "fabricloader": "*",
  "minecraft": "*",
  "soulfire": "*"
}

That keeps the plugin aligned with the SoulFire runtime instead of hardcoding narrow mod dependency rules.

Build output and installationCopy Anchor Link

Build the jar with:

./gradlew build

Then install the resulting jar into SoulFire's minecraft/mods directory and restart SoulFire.

What to copy directly from the templateCopy Anchor Link

Copy these without trying to be clever on day one:

• the Gradle wrapper
• the Loom plugin setup
• the version catalog structure
• the fabric.mod.json skeleton
• the mixin config skeleton
• the access widener file name wiring

Once the plugin works, then simplify the build.

Next stepsCopy Anchor Link

• Build Your First Plugin
• Mixins And Access Wideners
• Developer Resources