I’m in the thick of setting up a Gradle multi-project structure for my Minecraft mod, which was originally made for Forge, and now I’m trying to port it over to Paper. My project layout is pretty straightforward, consisting of a common module and two platform-specific modules (one for Forge and one for Paper). But I’m hitting a wall.
So here’s the situation: my `common` project isn’t recognizing any of the `net.minecraft.*` packages. I’ve looked everywhere for dependencies to include. I even scoured Maven for anything that could be of help, but I couldn’t find a `net.minecraft.*` dependency that would work. I’ve checked Forge’s build scripts since they contain the necessary dependencies for their loader, but they don’t translate to Paper. I’m starting to feel pretty lost here.
I’ve peeked at the repositories of a few others in the modding community to see how they tackle this multi-project approach. Some of them, like Geckolib, have a common project, but their build scripts just confuse me even more. How do I adapt their configurations to fit my needs? My current root project structure is simple enough:
“`
├── common/
│ ├── main/java/
│ │ └── …
│ └── build.gradle
├── forge/
│ ├── main/java/
│ │ └── …
│ └── build.gradle
├── paper/
│ ├── main/java/
│ │ └── …
│ └── build.gradle
├── settings.gradle
└── build.gradle
“`
In the `build.gradle` of my root project, I applied some basic settings and dependencies, ensuring that they would apply to all subprojects. Still, my `common` module just doesn’t know about any Minecraft classes, which feels like a huge red flag.
Could anyone shed some light on how to correctly configure the dependencies so that my `common` project can recognize the Minecraft code? What should I be looking for in terms of dependencies specific to Paper, and how can I structure these scripts to get everything aligned? Any insights would be super helpful!
Gradle Multi-Project Setup for Minecraft Mod
It sounds like you’re having a tough time syncing your common module with Minecraft’s net.minecraft packages, especially when transitioning from Forge to Paper.
Common Module Configuration
For your
common
module to recognize thenet.minecraft.*
packages, you’ll need to set up dependencies properly. Since Forge and Paper have different setups, it’s important to include the right dependencies for Paper in yourcommon
module.Step 1: Add Paper dependency
In your root
build.gradle
, make sure you’re specifying where to pull the Paper API from. You might want to add something similar to this:Step 2: Include Minecraft Dependencies
Since
common
should share code with both Forge and Paper, you’ll need to handle dependencies for both. In yourcommon/build.gradle
, try adding:This example pulls in the Spigot API, which is what Paper is built on. You might need to adjust the version to match your server’s version.
Step 3: Make Sure Modules Are Linked
Ensure that your
forge
andpaper
modules depend oncommon
. In their respectivebuild.gradle
files, add:Step 4: Syncing Gradle
After making these changes, sync your Gradle project. If done correctly, your
common
module should now recognize the Minecraft classes.Troubleshooting
If you’re still having issues, check your version numbers and make sure they match between your Minecraft server and the dependencies you’re including. Sometimes, other mods or plugins could also interfere. Make sure your
settings.gradle
properly includes all modules:Final Tip
Don’t hesitate to look at other open-source mods for their Gradle setups. They can provide a wealth of information to adapt to your structure. Good luck!
When working with a Gradle multi-project setup, especially for Minecraft modding involving different platforms, your
common
module should ideally contain interfaces and abstractions that are independent of platform-specific implementations. The problem arises because the vanilla Minecraft classes (net.minecraft.*
) are usually provided through platform-specific APIs (Forge, Fabric, Paper), and not available as standalone dependencies. For your Paper implementation, you typically depend on the Paper API (or Spigot API), accessible via their Maven repositories (likehttps://repo.papermc.io/repository/maven-public/
) and artifacts such asio.papermc.paper:paper-api
. However, the Paper API usually doesn’t expose the core Minecraft classes directly in an easily consumable way within acommon
module.A common solution is to restructure your
common
module to define only abstract functionality or interfaces, without direct references to Minecraft packages. Then, the platform-specific modules (Forge and Paper) would separately implement these interfaces using their respective platform-specific APIs. If you absolutely must share vanilla Minecraft code across your modules, consider creating an intermediate module, configured specifically for Paper, that depends on thepaper-api
, and reference it from your Paper module. Alternatively, you can use a runtime dependency (“provided” scope) within Gradle, but be aware this may limit certain compilation checks. Carefully examining build setups like Geckolib’s might help, but the key is abstracting shared code away from direct platform-specific dependencies into clearly defined interfaces or abstraction layers.