# AnvilGUI turns a Minecraft anvil into a text input field

> AnvilGUI is a MIT licensed Java library that captures player text input through an anvil inventory on Minecraft Java Edition without version-specific code, using reflection to load the right implementation at runtime. It is compiled against Spigot mappings, supports Minecraft 1.7 and later, and must be shaded into your plugin.

**WesJD/AnvilGUI** — Capture user input in Minecraft through an anvil GUI in under 20 lines of code

- Repository: https://github.com/WesJD/AnvilGUI
- Stars: 542 · Forks: 131
- Language: Java
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/wesjd-anvilgui

## What the library does and how little code it takes

AnvilGUI is a Minecraft Java Edition library that supports capturing user input from an anvil inventory without touching version-specific code. The pitch in the project description is under twenty lines of code, and the README's opening example is close to that. You build an AnvilGUI, attach an onClose callback that receives a state snapshot, attach an onClick callback that receives the clicked slot and the snapshot, and decide whether to prevent closing, then set the placeholder text and the inventory title, hand it the plugin instance and the player, and open it.

```java
new AnvilGUI.Builder()
    .onClose(stateSnapshot -> {
        stateSnapshot.getPlayer().sendMessage("You closed the inventory.");
    })
    .onClick((slot, stateSnapshot) -> {
        if(slot != AnvilGUI.Slot.OUTPUT) {
            return Collections.emptyList();
        }

        if(stateSnapshot.getText().equalsIgnoreCase("you")) {
            stateSnapshot.getPlayer().sendMessage("You have magical powers!");
            return Arrays.asList(AnvilGUI.ResponseAction.close());
        } else {
            return Arrays.asList(AnvilGUI.ResponseAction.replaceInputText("Try again"));
        }
    })
    .preventClose()
    .text("What is the meaning of life?")
    .title("Enter your answer")
    .plugin(plugin)
    .open(player);
```

The interesting design decision is visible in the callbacks. The onClick handler returns a list of response actions rather than performing side effects directly, so the library decides how the inventory reacts: close it, or replace the text the player typed with a different string. That is what lets the same code express validation, since a wrong answer can be rejected in place with Try again rather than closing the window and reopening it. The snapshot gives access to the text and to the player, and the onClose callback fires when the player dismisses the interface, which is where you clean up if you were tracking state. More usage detail lives in USAGE.md.

## The version directories and the reflection trick

The repository layout is the clearest explanation of how the library handles Minecraft's history. There are around thirty version-specific source directories, from 1_7_R4 and 1_8_R1 through 1_9_R1, 1_10_R1, 1_11_R1, 1_12_R1, 1_13_R1 and 1_13_R2, the 1_14 series, the 1_15 and 1_16 series, 1_17_1_R1, 1_17_R1, the 1_18 and 1_19 series, 1_20_R1 through 1_20_R4, 1_21_R1 through 1_21_R7, and 26_R1. Alongside them sit three directories that matter more than the version ones. The abstraction directory holds the version-independent API that plugin authors code against, the api directory holds the public interfaces, and the version directories hold the concrete implementations. The README explains that AnvilGUI works by loading the appropriate anvil implementation at runtime via reflection. That is the whole answer to how one library supports so many Minecraft versions, and it also explains the shading requirement described later, because a class that is only ever loaded reflectively looks unused to a static analyser.

## Maven coordinates and the repository move

The dependency is added through a Maven repository and a dependency block. A note at the top of the README records that the Maven repository for AnvilGUI has moved as of version 1.10.11-SNAPSHOT, and gives both the old and the new form, with the old one pointing at the CodeMC repository and the new one at the project's own host.

```xml
<repository>
    <id>mvn-wesjd-net</id>
    <url>https://mvn.wesjd.net/</url>
</repository>

<dependency>
  <groupId>net.wesjd</groupId>
  <artifactId>anvilgui</artifactId>
  <version>1.10.13-SNAPSHOT</version>
  <scope>compile</scope> <!-- Include the library in your JAR -->
</dependency>
```

Two details in that block are worth noticing. The scope is compile rather than provided, with the comment explaining that this includes the library in your JAR. And the version shown there is a development build, which for a library distributed from a personal Maven host rather than Maven Central is normal rather than alarming. The repository has no GitHub releases, so the Maven repository is effectively the distribution channel, and the last push to the repository was on 2026-10-12.

## Shading is mandatory, and minimising your JAR will break it

Because AnvilGUI is a library, it must be shaded into your plugin, and the README gives the example shade configuration with two reasons for doing it: to avoid classpath conflicts with other plugins, and to avoid breaking the library when minimising your JAR. The shade configuration is long but its two halves are the point. The first half relocates net.wesjd.anvilgui into your own plugin namespace, with the comment explaining that if multiple plugins use AnvilGUI at different versions, one of the plugins' functionality may break unless you relocate it. The second half is the filter, and it exists for a reason the README spells out. AnvilGUI loads the appropriate anvil implementation at runtime via reflection, so when minimise JAR is enabled the shade plugin sees no usages of the anvil implementation classes and omits them from the shaded artifact. The fix is a filter that always includes the entire library. The version of the shade plugin must be at least 3.5.0, and the include pattern covers the whole net.wesjd.anvilgui package path. Skipping the filter produces a plugin that compiles cleanly and fails at runtime, which is the worst kind of bug to diagnose.

## Spigot mappings, Bukkit plugins and Paper plugins

The requirements section lists Java 8 or later, Bukkit, Spigot or Paper for Minecraft 1.7 and later, and Spigot mappings. The mapping requirement is the one that catches people out. AnvilGUI is compiled against Spigot mappings, and Mojang mappings are not supported at runtime. You can still develop using Mojang mappings when using Paperweight. The plugin type matters too. Your plugin is a Bukkit plugin if it contains a plugin.yml and does not contain a paper-plugin.yml, and Bukkit plugins use Spigot mappings by default, though you can still use the Paper API even if your plugin is a Bukkit plugin, since the Paper plugin system adds features on top of the Paper API but is not needed to use it. A Paper plugin is one that contains a paper-plugin.yml, even if plugin.yml is also present, and Paper plugins do not use Spigot mappings by default, so you must enable them explicitly through the manifest. If you access server internals in a Paper plugin, you need to reobfuscate it to Spigot mappings, which with the Paperweight Userdev toolchain means enabling the reobfArtifactConfiguration option.

## Where AnvilGUI is the wrong choice

Three limits. The first is that an anvil input is not always the right UI for a plugin. An anvil inventory is a text field with no validation built in, no dropdown, no paging, and a visible label the player has to interpret, so for anything with a small fixed set of answers a chest menu with named items is both easier for the player and less code for you. The second is the shading commitment. Every plugin that depends on AnvilGUI carries a relocated copy of the library and the shade configuration to maintain, and the relocation pattern has to be updated when the package changes. Relocating net.wesjd.anvilgui into your plugin namespace also means you cannot share the library between your own plugins without conflicts. The third is the mapping constraint. Compiling against Spigot mappings and reobfuscating Paper plugins is extra ceremony, and a project that has standardised on Mojang mappings or that targets Bedrock or modded servers is outside what this library supports. None of these are reasons to avoid it for a plugin that genuinely needs free text, but they are reasons to think before adding a shading pipeline to a project that does not have one.

## Conclusion

Adopt AnvilGUI if your plugin needs free-form text from a player and you want to avoid handling version-specific anvil internals yourself. Skip it if a chest menu with buttons would do, since an input field is more work to get right. Before you integrate, decide on your shading and relocation setup, because the README warns that minimising your JAR without a filter silently drops the anvil implementation classes, and use Spigot mappings at runtime since Mojang mappings are not supported.

## FAQ

### What does the AnvilGUI library do?

It captures player text input through an anvil inventory on Minecraft Java Edition without version-specific code, using reflection to load the right anvil implementation at runtime. The API is a builder with onClose and onClick callbacks that return response actions such as closing the inventory or replacing the typed text.

### How do I add AnvilGUI to a Maven project?

Add the repository at https://mvn.wesjd.net/ and the dependency net.wesjd:anvilgui with scope compile, so the library is included in your JAR. The README notes that the Maven repository moved as of version 1.10.11-SNAPSHOT from the CodeMC snapshots repository.

### Why does the shade configuration need a filter?

AnvilGUI loads the anvil implementation classes at runtime via reflection, so when minimise JAR is enabled the shade plugin sees no usages and omits them from the shaded artifact. The filter always includes the whole net.wesjd.anvilgui package path to keep them, and the shade plugin version must be at least 3.5.0.

### Which Minecraft versions and mappings does AnvilGUI support?

It requires Java 8 or later and Bukkit, Spigot or Paper for Minecraft 1.7 and later. It is compiled against Spigot mappings, and Mojang mappings are not supported at runtime, though you can develop with Mojang mappings using Paperweight. Paper plugins must enable Spigot mappings explicitly and reobfuscate if they access server internals.

## Sources

- [Issues](https://github.com/WesJD/AnvilGUI/issues)
- [License: MIT](https://github.com/WesJD/AnvilGUI/blob/master/LICENSE)
- [README](https://github.com/WesJD/AnvilGUI/blob/master/README.md)
- [WesJD/AnvilGUI on GitHub](https://github.com/WesJD/AnvilGUI)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/wesjd-anvilgui