1
1
Fork 0
Compile-time Annotation Processor for Paper's Brigadier API
Find a file
2026-04-01 13:01:13 +01:00
gradle Update dependencies, changelog, and version number 2026-04-01 12:58:55 +01:00
src/main Fix @Word and @Greedy annotations 2026-04-01 12:52:36 +01:00
.gitattributes Initial Commit 2025-08-03 15:34:50 +01:00
.gitignore Initial Commit 2025-08-03 15:34:50 +01:00
build.gradle.kts Update dependencies, changelog, and version number 2026-04-01 12:58:55 +01:00
changelog.md Remove the v prefix from tag names 2026-04-01 13:01:13 +01:00
gradle.properties Initial Commit 2025-08-03 15:34:50 +01:00
gradlew Initial Commit 2025-08-03 15:34:50 +01:00
gradlew.bat Initial Commit 2025-08-03 15:34:50 +01:00
license.md Initial Commit 2025-08-03 15:34:50 +01:00
readme.md Update dependencies, changelog, and version number 2026-04-01 12:58:55 +01:00
settings.gradle.kts Initial Commit 2025-08-03 15:34:50 +01:00

Brigadier Processor

The Htmx of Bukkit/Paper Command Frameworks.

Warning

Brigadier Processor is still "alpha quality", there will be bugs, missing features, etc. Make sure to report any bugs quickly so they can be fixed.

Throughout the history of Bukkit, there have been numerous different ways to register and manage commands. Often these days plugins will use command frameworks such as Aikar's Annotation Command Framework and Incendo's Cloud, the issue is that these are rather bulky dependencies that duplicate a lot of work already done by Minecraft's built in Brigadier command manager.

In more recent versions, Paper has exposed Brigadier as part of it's API, allowing plugins to register commands directly through it, rendering these bulky command frameworks almost obsolete (they support non-minecraft contexts, and so are still useful there). However there is one major gap in Paper's Brigadier API: Annotations.

Some developers prefer to define their commands using annotations as opposed to directly calling functions, and some go as far as to prefer their commands to be automatically registered, without maintaining a central "register all commands" function.

Brigadier Processor provides this functionality using a compile-time annotation processor, filling a gap in Paper's API, and providing a lighter alternative to these command frameworks.

Using Brigadier Processor

Add the following to your build.gradle.kts file.

plugins {
	id("com.google.devtools.ksp") version "2.3.6"
}

repositories {
	maven("https://repo.astralchroma.dev/public/")
}

dependencies {
	compileOnly("dev.astralchroma:brigadier-processor:0.1.2")
	ksp("dev.astralchroma:brigadier-processor:0.1.2")
}

ksp {
	arg("package", "com.example.plugin")
}

Then in your PluginBootstrap add.

context.lifecycleManager.registerEventHandler(COMMANDS, Registration(context.logger))

And in your JavaPlugin, add.

Registration.listeners(this)

Then you are free to use the processor's annotations defined in dev.astralchroma.processor.annotations.

Frequently Asked Questions

Java support?

The current version of the processor is fairly minimal and currently only supports Kotlin. Java will be supported in the future once the processor is cleaned up / refactored.

Why only compileOnly?

The Brigadier Processor does not exist at runtime, only compile time. The only runtime code involved is a generated Registration.kt file derived from annotated objects, classes, and functions.

Why does command processing take so long?

The Brigadier Processor doesn't currently incrementally process and generate it's data and final output. This will be improved in the future. It is worth noting however that this does avoid processing happening during server startup, avoiding potentially multiple seconds.