Build Tooling Overview
build-logic is the Gradle convention toolkit that builds MagicUtils itself,
and it is reusable: several mods already build on it. Instead of copying Gradle
boilerplate between projects, you apply a small set of magicutils.* plugins and
describe your project declaratively.
It gives you:
- A multi-target matrix so one source tree builds against many Minecraft versions (and Java levels) without per-version branches. See Target Matrix.
- Consumer plugins (
magicutils.consumer-*) that wire MagicUtils into your Bukkit/Fabric/Velocity/Bungee/NeoForge module with a few lines. See Using It In A Mod. - Publishing to the self-hosted Reposilite Maven repo and to Modrinth. See Publishing.
- Dev servers and compatibility smoke tests gated on runtime diagnostics. See Dev Server & Smoke.
- Aggregated, themed Javadoc for the whole API. See Aggregated Javadoc.
Where It Lives
The build-logic plugins are published to the MagicUtils Reposilite repo, so a
consuming project resolves them by version like any other Gradle plugin. Declare
the repositories and plugin versions in pluginManagement, then apply the matrix
settings plugin at the top level:
mavenLocal() lets you develop against a locally published build-logic; on CI
and other machines it resolves from maven.theroer.dev. includeBuild(...) is
not used for build-logic here — that mechanism only appears inside the
MagicUtils repo itself, or optionally in a consumer to substitute a local
checkout of the library (not the build tooling).
The Two DSLs
Two extensions drive everything:
magicMatrix { }insettings.gradle.ktsdeclares the target matrix, the common vs platform module split, scenarios, and the publish/smoke config.magicutilsConsumer { }in a module'sbuild.gradle.ktsdeclares how that module consumes MagicUtils (version, embedded vs shared, which modules, and an optional dev server).
The pages in this section cover each area in turn.