MultiLoader Template: one Minecraft mod source tree, several loaders

A skeleton, deliberately empty of dependencies

The MultiLoader Template provides a Gradle project template that can compile Minecraft mods for multiple modloaders using a common project for the sources. The README is emphatic about one thing: the project does not require any third party libraries or dependencies.

That sentence decides what this is. It is not a modding library, not an abstraction layer over the loaders, and not a code generator. It is a build layout, with the folder structure, the Gradle configuration and the module boundaries that a multi loader mod needs, and nothing else.

That is a useful thing to have, because the multi loader setup is the part every project has to solve and most get wrong. The structure enforces a rule that is easy to state and easy to break: the shared code cannot know about any single loader, and the loader specific code is where the differences live. A template that enforces that at the Gradle level saves every project from rediscovering it.

The template is developed with a community, and the README points at a Discord server for questions and discussion. The licence is CC0, which is a public domain dedication rather than a software licence, which is consistent with a template rather than a library: there is nothing here to attribute in the ordinary sense.

The default branch is named for a version, and the repository has no tagged releases, so the project treats the branch as the artefact.

The common project is where your mod lives

The development guide is short and it is the part you will live with.

When using this template, the majority of your mod should be developed in the common project. The common project is compiled against the vanilla game and holds the code that is shared between the different loader specific versions of your mod.

The critical constraint is that the common project has no knowledge or access to modloader specific code, APIs or concepts. Code that requires something from a specific loader must be written in the project for that loader, such as the fabric or neoforge projects.

That constraint is the entire value proposition, and it is worth being precise about why it is enforced rather than merely recommended. A loader specific API called from common code compiles fine in one loader and fails in the other, and it usually fails at runtime in a way that is hard to diagnose. Making the common project physically unable to see loader code turns that class of bug into a compile error in the loader project instead.

It also has a pleasant side effect for the project layout. Because common is compiled against the vanilla game, the shared code is the part of your mod that is, in principle, loader independent, and the parts that differ are visibly separated into their own directories.

The loader projects, and the one-way dependency

The loader specific projects, such as fabric and neoforge, are used to load the common project into the game. They also define the code that is specific to that loader.

The dependency rule is stated plainly: loader specific projects can access all the code in the common project, and it is important to remember that the common project cannot access code from loader specific projects.

So the structure is a one-way flow. The loader project depends on common; common depends on nothing loader specific. That is what lets a single source tree produce a Fabric build and a NeoForge build, with the loader project acting as the adapter that puts the shared code into each loader's runtime.

The repository layout mirrors this exactly. There is a common directory, a fabric directory, a neoforge directory, a build-logic directory for the convention plugins that configure the build, a top level build file, the settings file that includes the subprojects, the Gradle wrapper and the properties file where you set the versions and names.

The interesting design decision is that the build logic is a separate included build rather than a set of shared scripts in the root, which is how the subprojects can each apply the same conventions without the root build having to know about them.

And the entries can be added as well as removed, because the template is meant to be edited rather than consumed. The removal procedure is the simplest part of the whole arrangement.

Setting up in IntelliJ, and the Java 25 requirement

The IntelliJ guide is the primary setup path, and the README says it should be familiar to anyone who has worked with the modloader development kits, since the process is roughly equivalent to setting the loaders up independently.

The steps are six. You clone or download the repository. You configure the project by setting the properties in the gradle.properties file, and you also need to change the rootProject.name property in the settings file so that it matches the folder name of your project, or IDEA may complain. You open the root folder, the one containing the readme and the Gradle wrapper executable, as a new project. You point the IDE at the right JDK. You reload the Gradle project. And then you pick a run configuration.

The JDK step is the one that will trip you up. If your default JVM is not Java 25 you will encounter an error when opening the project, and the fix is to change the Gradle JVM in the build tools settings and to set the Project SDK in the project structure dialog, and then reload from the Gradle tab.

The run configurations come from the two loaders in different categories: under the Application category there are options to run NeoForge projects, and under the Gradle category there are options to run Fabric projects. The README's advice is to select one of the client options and try it, and if the game runs your workspace is set up.

That last check is the practical one. The template gives you a working client for each loader, which is how you confirm the build logic and the JDK before you write any mod code at all.

Why Eclipse is not supported

The README is unusually direct about Eclipse, and the explanation is worth reading because it says more about Gradle than about modding.

While it is possible to use the template in Eclipse, it is not recommended. During the development of the template, multiple critical bugs and quirks related to Eclipse were found at nearly every level of the required build tools. The team continues to work with those tools to report and resolve issues, but support for projects like this is not there yet, and Eclipse is considered unsupported by the project. The reason given is that the development cycle for build tools is notoriously slow, so there are no estimated times available.

Two things are worth drawing out of that. The first is that the problem is not in the template but in the layers beneath it, which is a common and underappreciated shape of problem: the build tooling, not the project. The second is the honesty about the response, since a template that quietly does not work in a popular IDE would be much worse than one that says so.

It also has a practical consequence for your tooling. If you are an Eclipse user, this template is not for you, and the README points at the equivalent setup for the modloader development kits as the alternative path, since the process is roughly equivalent to setting the loaders up independently.

Adding and removing loaders

The template supports many modloaders, and the README is clear that this is not fixed. New loaders may appear in the future, and existing loaders may become less relevant.

Removing one is deliberately easy. You delete the subproject folder, for example the forge folder inside the template, and you remove the include line for that project from the settings file, for example the line that includes forge.

Two steps, no other coupling. That is the payoff of the structure, and it is why the README frames the template as something you edit rather than something you depend on. A loader that is losing users is removed by deleting two things, and the build does not need to be told about it in a configuration file somewhere else.

The same simplicity applies to adding one, which is what makes the template a reasonable base for a mod that wants to support a loader the template does not ship yet.

On the state of the project, the facts are modest but healthy. The default branch is named for the version it targets, the last push was on 2026-10-01, and there are no GitHub releases, so a template user follows the branch rather than pinning a version. The topic list carries the Hacktoberfest tag, which explains the shape of the contributor base.

Editorial conclusion

MultiLoader Template suits a Minecraft mod author who wants to ship on more than one loader without maintaining two code bases, because the shared project holds the game logic and the loader projects hold only what differs, and the removal instructions make it easy to drop a loader you no longer care about. It is the wrong choice if you want a batteries included modding framework, because the template deliberately has no third party dependencies, and the wrong choice if your editor is Eclipse, which the project states is unsupported. Verify first that the loaders listed in your settings file match the ones you publish on, that the project name property matches your folder so the IDE does not complain, and that you are on Java 25, which the template requires and does not negotiate.

Frequently asked questions

Official sources

1. Issues
2. jaredlll08/MultiLoader-Template on GitHub
3. License: CC0-1.0
4. README