> For the complete documentation index, see [llms.txt](https://wyne.gitbook.io/wyne-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wyne.gitbook.io/wyne-docs/lootpool/building-from-source.md).

# Building from source

Clone with submodules, build the shaded plugin jar, run a test server, and publish the API to Maven Central.

## What you need

Git and a JDK to run Gradle with. The Gradle wrapper fetches Gradle itself, and the build provisions the JDKs it actually compiles and runs with: Java 16 for compilation, and a JetBrains Runtime 21 for the test server.

## Clone

`gradle/libs.versions.toml` is a symlink into the `libs` submodule, which holds the version catalog shared across these plugins. A clone without it fails while Gradle configures the build:

```bash
git clone --recurse-submodules https://github.com/Wyne10/LootPool.git
```

If you already cloned without `--recurse-submodules`, run `git submodule update --init`.

## Build

```bash
./gradlew shadowJar
```

The shaded plugin jar lands in `build/libs/LootPool-<version>.jar`, ready to drop into a server's `plugins/` folder. It bundles the Kotlin runtime, Guice, WUtils and EnhancedLegacyText, and relocates Guice, Guava, WUtils and EnhancedLegacyText under `me.wyne.lootpool.shadow`, so the plugin can't collide with another plugin bundling the same libraries.

| Command                            | What it does                                                                          |
| ---------------------------------- | ------------------------------------------------------------------------------------- |
| `./gradlew shadowJar -Pdebug=true` | Builds without relocating anything, which keeps stack traces readable while debugging |
| `./gradlew :api:build`             | Builds the consumer API module on its own                                             |
| `./gradlew clean shadowJar`        | Rebuilds from scratch                                                                 |

The project version lives in `gradle.properties` and names both the jar and the published API artifact.

## Run a test server

```bash
./gradlew runServer
```

This downloads Paper 1.16.5 along with CommandAPI, LuckPerms, PlaceholderAPI, ProtocolLib, ViaVersion, and ViaBackwards, then starts a server in `run/` with the freshly built plugin installed. Add `-Pdebug=true` to run on 1.19.4 instead, with relocation off.

The server keeps its pools in `run/plugins/LootPool/lootpool/` and its enchantment pools in `run/plugins/LootPool/enchantment/`. Try `/lootpool pool create test`, then `/lootpool preview test`.

## Project layout

| Module | Contents                                                                                                                                                                                    |
| ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `api`  | Pure Java on Java 16, one `compileOnly` dependency on the Paper API. Every pool type, entry, modifier and condition, plus `LootPoolProvider` and `LootPoolApi`. Published to Maven Central. |
| root   | The plugin: Kotlin, Guice, the commands, the editors and the registries. Not published as a dependency.                                                                                     |

Anything that needs Kotlin, PlaceholderAPI or the plugin's own utilities belongs in the root module, not in `api`. See [Extending LootPool](/wyne-docs/lootpool/extending-lootpool.md) for where each kind of addition goes.

## Publish the API

The `api` module is the only thing published; the plugin jar itself is distributed as a jar, not as a dependency.

To try a release locally, into `~/.m2`:

```bash
./gradlew :api:publishToMavenLocal
```


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://wyne.gitbook.io/wyne-docs/lootpool/building-from-source.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.