Using It In A Mod
The magicutils.consumer-* plugins wire MagicUtils into your own module. Instead
of declaring dependencies, shadow config, and run tasks by hand, you apply one
plugin per platform module and describe what you need in magicutilsConsumer { }.
Apply The Plugin
Each platform module applies the matching consumer plugin. It brings in
java-library, the shadow plugin, and the MagicUtils target/repository
conventions:
The plugin version is declared once in pluginManagement (see
Overview), so the module just applies it by id:
The consumer plugin per platform:
magicutils.consumer-bukkitmagicutils.consumer-fabricmagicutils.consumer-velocitymagicutils.consumer-bungeemagicutils.consumer-neoforge
Embedded vs Shared
embedMagicUtils (default true) controls whether MagicUtils is shaded into
your artifact or expected as a separate install on the server:
You can also set it from the command line or gradle.properties with
-Pmagicutils_embed=false. See Installation for
the embedded vs shared trade-off.
Selecting Modules
Declare the MagicUtils modules your code needs. The plugin resolves them to the right coordinates for the active target:
Multi-Target In A Consumer
Because the consumer applies magicutils.target, your own module is also
target-aware. Build or run it against a specific target with -Ptarget:
This is what lets one mod source tree ship against several Minecraft versions,
which is the point of building on build-logic.
Optional Dev Server
Opt into a run task with devServer { }. Conventions cover the common case, so
devServer() with no body is enough to get a Paper/Folia/Fabric/Velocity runner:
That registers the platform's run task (runPaper, runFolia, runFabric,
runVelocity), covered in Dev Server & Smoke.