PluginUtils is MCME's shared helper library for Paper plugins: chat messages with clickable parts, confirmation prompts, regions, a plot storage format, thin access to server internals, and small helpers for WorldEdit and Dynmap. It runs on the server as a plugin of its own, and other plugins compile against it and declare it as a dependency; they never bundle it. The current line is 2.0.x for Paper 26.2, and the latest release is 2.0.6.

• Repository: github.com/MCME/PluginUtils
• Artifact: com.mcmiddleearth:PluginUtils on the Maven repository
• Used by, among others: MCME-Architect (2.0.4), MCME-PvP (2.0.4), Guidebook (2.0.4) and MCME-Connect (2.0.2)

What is in it

All classes are under com.mcmiddleearth.pluginutil.

The plugin itself

The PluginUtils jar is a plugin (load: STARTUP) with one command:

It soft-depends on ProtocolLib, Essentials, WorldEdit and dynmap. It has no config file.

Using it in a plugin

Compile against it, declare it in plugin.yml, and let the server provide it. Do not shade it.

Gradle

repositories {
    maven { url = 'https://repo.mcmiddleearth.com/releases' }
}
dependencies {
    compileOnly 'com.mcmiddleearth:PluginUtils:2.0.6'
    // Only if your tests load PluginUtils classes (for example with MockBukkit):
    testImplementation 'com.mcmiddleearth:PluginUtils:2.0.6'
}

Maven

<repositories>
    <repository>
        <id>mcme-releases</id>
        <url>https://repo.mcmiddleearth.com/releases</url>
    </repository>
</repositories>

<dependency>
    <groupId>com.mcmiddleearth</groupId>
    <artifactId>PluginUtils</artifactId>
    <version>2.0.6</version>
    <scope>provided</scope>
</dependency>

plugin.yml

depend: [PluginUtils]

Things to know:

• Build with JDK 25. PluginUtils 2.0.x is Java 25 bytecode. In Gradle, use a Java 25 toolchain; a build that targets older bytecode cannot resolve it ("only compatible with JVM runtime version 25 or newer").
• json-simple comes along. PluginUtils' one dependency is json-simple 1.1.1, which the Paper server also ships. Since 2.0.4 it is declared in the published POM and Gradle module, so it lands on your compile and test class paths but never in your jar.
• Don't use JitPack's coordinate (com.github.MCME:PluginUtils) for anything you deploy. JitPack can build any commit, which is handy to try one, but its group id differs, and a build that also gets com.mcmiddleearth:PluginUtils (directly or through another MCME artifact) ends up with two copies.
• Anything built against a version older than 2.0.2 breaks on 26.2. 2.0.0 and 2.0.1 were compiled against Minecraft 26.1.2, whose internals differ; such builds fail with NoSuchMethodError: Entity.saveWithoutId. The public API has not changed since 2.0.2, so plugins built against 2.0.2 or later need no rebuild for a newer PluginUtils.

Building

./gradlew build

The build uses paperweight-userdev, which resolves paper-api and the server's internal classes from PaperMC's published dev bundle (26.2.build.111-stable). There is no local server jar to place by hand, so it builds on any machine and in CI. The first build downloads and decompiles the Paper server, which takes a few minutes; later builds use the cache. The jar lands in build/libs/.

• Gradle 9.0.0 comes with the wrapper; you don't need Gradle installed.
• paperweight-userdev is pinned to 2.0.0-beta.23, not its moving 2.0.0-SNAPSHOT. Releases from beta.24 on need Gradle 9.7.1, so upgrade the plugin and the wrapper together.
• Tests run on JUnit 6 and MockBukkit 4.116.1 (mockbukkit-v26.2) against paper-api 26.2.build.126-stable. The server jar from the dev bundle is kept off the test class path, because its service providers clash with MockBukkit's.
• The jar is reproducible across systems. processResources fills ${project.version} into plugin.yml and writes it with LF line endings, so a Windows build gives the same jar as CI on Linux.

CI (.github/workflows/build.yml) builds every push to master and development, every pull request and every tag, on ubuntu-26.04 with Temurin 25.

Branches and releases

Both master and development are protected. The legacy 1.9.x line (Paper 1.21.x, a Maven build that needed a local server jar) ends at commit f17ced6.

To release (from the README):

1. On a branch from development, set version in build.gradle, move the [Unreleased] notes in CHANGELOG.md into a dated section, and update the version in the README. Commit it as release: PluginUtils X.Y.Z — <what changed> and open a pull request into development.
2. When CI is green and the pull request is merged, tag the release commit with an annotated, bare tag (2.0.6, not v2.0.6) and push it. CI then publishes that version to the Maven repository. releases refuses to overwrite a version, so check the published POM, module and jar afterwards.
3. Open a pull request from development into master.
4. On development, start the next version: version = 'X.Y.(Z+1)-SNAPSHOT'.

Release history (2.0.x)

CHANGELOG.md has the full notes.