dynmap: one Minecraft map plugin carried by twenty separate builds

A map plugin, and the table that decides which jar you need

The repository description states the scope plainly: a set of Minecraft mods providing a real time web-based map system for various server implementations. The word various is doing the work, and the platform table below it is the first thing any new user needs.

| Server type  | Version | Dynmap JAR | Where? |
| ------------ | ------- | ---------- | ------ |
| Spigot/PaperMC | ≤1.21.4  | `Dynmap-<version>-spigot.jar` | [SpigotMC](https://www.spigotmc.org/resources/dynmap%C2%AE.274/) |
| Forge | 1.12.2 - 1.20.6 | `Dynmap-<version>-forge-<MC_VERSION>.jar` | [Curseforge](https://www.curseforge.com/minecraft/mc-mods/dynmapforge) |
| Fabric | 1.14.4 - 1.21.4 | `Dynmap-<version>-fabric-<MC_VERSION>.jar` | [Curseforge](https://www.curseforge.com/minecraft/mc-mods/dynmapforge) |

Four rows cover two server families and, more importantly, define a jar naming convention you have to match. The Spigot and PaperMC build is version independent because that platform's API is stable across the range, while Forge and Fabric builds are pinned per Minecraft version, since mod loaders break their APIs between releases. Each row also names a distribution channel, and Spigot appears twice because the same jar is published to both SpigotMC and Modrinth.

The topics confirm the fan-out: fabricmc-mod, forge-mod, minecraft-mod, papermc-plugins and spigotmc-plugins. There are 186 open issues on the repository, which is high for a plugin but proportionate to a project supporting that many combinations, and the homepage points at a subreddit rather than a documentation site.

One Gradle build that has to survive every platform

Building is two commands in a modern checkout, and the JDK story is the interesting part:

./gradlew setup build

Dynmap 3.x and later use Gradle 8.7 and put every artifact in the `targets` directory. Because Minecraft 1.18 and later require it, the default JDK for a developer must be 21, yet the compiled output still targets the older JDK each platform needs: 8 for 1.16 and earlier, 16 for 1.17.x, 17 for 1.18 through 1.20.4, and 21 from 1.20.5. Common libraries are built on JDK 8.

That produces a two-tier setup, which is what makes this project unusual to contribute to. The legacy Forge 1.12.2 builds use ForgeGradle and are described as very sensitive to being built by JDK 8, so they live in a separate `oldgradle` directory with their own wrapper:

cd oldgradle
./gradlew setup build

A single change therefore has to be built twice, in two Gradle builds, under two different JDKs. That is the mechanism behind the contributing rule that pull requests must be built and tested for all platforms including oldgradle or be rejected. The same directory can also be targeted directly, which is how a contributor narrows a build while iterating:

./gradlew :fabric-1.18:build

The README is careful that this shortcut is for local iteration and not suitable for uploading development changes.

The tree is a directory per platform and version pair

The repository tree is the clearest statement of the project's real cost. Alongside `DynmapCore/`, `DynmapCoreAPI/` and `dynmap-api/`, which hold the shared code, there are around twenty build directories.

The Spigot side runs from `bukkit-helper-113-2/` through `bukkit-helper-121-11/`, a series that maps onto plugin API versions with suffixes for patch levels. Forge has its own run, `forge-1.12.2/` up to `forge-1.21.11/`. Fabric starts later, at `fabric-1.14.4/`, and runs to `fabric-1.21.11/`. Nothing here is a sample app or a documentation folder. Every one of those directories exists so a single shared codebase can be compiled against a different platform API.

The shared directories are where the contributing rules draw a firm line. Changes to `DynmapCore` or `DynmapCoreAPI` are only accepted if the contributor is ready to build and test on all supported platforms, because code that breaks the build of any supported platform is rejected outright. That is a rational rule for a project with this shape and an intimidating one for a newcomer, since the cost of a small fix is now a full matrix run.

The rest of the root is ordinary build configuration: `build.gradle`, `gradle.properties`, `buildspec.yml` for AWS, `.spellcheck.yaml`, `CLAUDE.md` and `.vscode/`. The presence of a `CLAUDE.md` at the root is a small signal about how contributions are handled here.

Storage backends, and why the default matters less than it sounds

Dynmap supports seven storage backends and the first one is labelled the default for a new installation. Flat files are that default. The rest are MySQL, SQLite, PostgreSQL, MariaDB and AWS S3.

Two annotations carry the practical detail. The PostgreSQL entry notes that the JDBC driver is bundled with the Dynmap jar, which saves you a step. The MariaDB entry is more interesting because it is compatible with MySQL but needs a nudge: set `storage-type` to `mysql` for it to be recognised, or inject the MariaDB driver classes yourself. The S3 entry goes further and notes that the bucket can serve as the storage location and as the website host at the same time.

Then there is a footnote about SQL drivers, which is where a Forge or Fabric user is likely to get stuck. Drivers for SQL are usually already present on Spigot and its derivatives, but they are not included with other platforms or with Dynmap. For Forge and Fabric servers the README recommends Kosma's SQLite mod or MySQL mod from Curseforge to add the missing drivers, and notes that injecting driver classes into the jar file is also recognised and supported.

The practical summary is that flat files work everywhere with no setup, and that choosing a database buys you nothing until you have solved the driver problem for your platform. MySQL on Spigot is the easy path to a real database; PostgreSQL on Fabric is not.

A contributing guide written as a list of refusals

The contribution section is the most unusual document in the repository and worth reading even if you never open a pull request, because it explains the project's constraints better than the feature list does.

It opens by reserving the right to reject any pull request for any reason, with an honest justification: accepting a change also means accepting the cost of supporting it, explaining it to users, and fixing its current and future problems. From there the rules are specific. Keep pull requests small, do not lump multiple features into one, and do not make formatting-only changes, since those produce large diffs that are hard to review and cause merge conflicts for the many people who fork Dynmap for private builds.

Two constraints are stated as absolutes. First, no platform-specific native libraries or command line behaviour, because Dynmap runs on 32 and 64 bit machines, many Linux distributions on x86 and ARM, macOS and Docker, and the intent is to stay as pure Java as a Minecraft server. Second, no new unconditional requirements, so a database can be supported as an option but cannot become mandatory, since the minimum has to stay at what a server plus the plugin needs.

The last two are the ones that shape the codebase. Any contributed code and all dependencies must compile and run on Java 8, and no other language may be introduced: no Kotlin, no Scala, no JRuby, on the grounds that they add runtime dependencies most platforms lack and raise the skill bar for contributors. A Java 8 floor in 2026 is a real constraint on library selection, and it is the single most useful thing to know before proposing a dependency.

Release history suggests the tags are not the current version

The published releases are the part of this repository most likely to mislead. The three releases in the history are v3.3-beta-2 from December 2021, v3.2.1 from October 2021 and v3.1-beta-7. Every one of them is a beta or a patch from 2021, and two of the three are from the same month.

Those notes still describe real work. v3.3-beta-2 added a new chunk manager with support for 3D biomes and a claimed twenty to twenty-five percent render performance improvement on 1.16.5, 1.17.1 and 1.18.x, reverted a snakeyaml update to fix parsing of Windows-formatted yaml, and avoided an initial error when no markers.yml file exists on first installation. v3.2.1 added Forge 1.16.5, Forge 1.17.1 and Fabric 1.17.1 support, fixed missing blocks for 1.17, moved player image loading off the server thread under all conditions, and disabled a broken reload command until it could be fixed.

Set against that, the last push was 2026-09-26 and the support table covers versions up to 1.21.4. Both facts are in the repository and neither contradicts the other, but the conclusion is that the release tags are a stale view of the project. The current build is on Curseforge and Modrinth, which is where the README points you, and the GitHub releases list should not be treated as a version history for deciding what to install.

Editorial conclusion

Dynmap is the mature answer to wanting to see your Minecraft world from a browser, and its support breadth is the reason it has accumulated 2225 stars and 493 forks. What that breadth costs is visible in the tree: roughly twenty platform directories, a build that must succeed everywhere before a change lands, and a contributing guide that reads like a warning notice. Start by picking the jar for your exact platform and version from the support table rather than assuming the newest build works, configure the storage backend deliberately since flat files are only the default, and read the pull request rules before you plan to contribute anything.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. webbukkit/dynmap on GitHub