Project Layout

Project Layout

EverNifeCore is a Gradle multi-project build. The guiding rule is that the core logic is platform-agnostic: the common module never imports Bukkit or Hytale, and each platform module ships the concrete implementation on top of it. This page maps the modules to what they produce.

The modules, as declared in settings.gradle:

EverNifeCore/
├── api-contracts/                # compile-time stub classes (the "platoverride" pattern)
├── common/                       # platform-agnostic core - zero Bukkit imports
├── minecraft/                    # Bukkit/Spigot/Paper plugin - produces the deployable JAR
│   └── modules/
│       ├── VersionedPlugins/     # WorldGuard/WorldEdit adapter layer (needs spigot-api)
│       ├── v1_7_10/              # WorldGuard/WorldEdit compat for the 1.7.10 API
│       ├── v1_12_2/              # WorldGuard/WorldEdit compat for the 1.12.2 API
│       └── v1_16_5/              # WorldGuard/WorldEdit compat for the 1.16.5 API
├── hytale/                       # Hytale platform port
└── libby/                        # runtime dependency loader (a Libby fork)

---

The modules

common

The platform-agnostic core: the command framework, argument parsing, localization, FancyText, placeholders, cooldowns, player data, config integration, scheduler, and the FC*Util helpers. It has zero Bukkit imports - platform behavior reaches it through the provider/platform abstraction (see Platform Abstraction).

Published as two artifacts: evernifecore-common (normal view) and evernifecore-common-relocated (Jackson relocated to the br.com.finalcraft.everydatabase.libs.* names the deployed core carries at runtime). A platform-agnostic downstream module compiles against the relocated view - see Installation.

api-contracts

Compile-time stub classes only. common references a handful of types whose real implementation is platform-specific (FPlayerAdapter, ArgumentoAdapter, MinecraftArgumento, McFCScheduler, HyFCScheduler, IECBaseListener, GameVecPlatformAdapterConverter); it declares compileOnly project(':api-contracts') to compile. Each platform module ships the real class under the same fully-qualified name, which replaces the stub at runtime. The stubs are never packaged into any final JAR. This is the "platoverride" pattern - the mechanism is detailed on Platform Abstraction.

minecraft

The Bukkit/Spigot/Paper implementation - everything under br.com.finalcraft.evernifecore.minecraft.*: the entry point, the platform providers, item/NBT builders, the GUI framework, Vault/PAPI/WorldEdit integrations, and version detection.

This module produces the deployable plugin JAR, via the shadowJar task:

./gradlew :minecraft:shadowJar

The default jar task is disabled - minecraft:build alone produces nothing useful. The shadow jar bundles the runtime dependencies and relocates them under br.com.finalcraft.libs.* so they never clash with other plugins. The output is EverNifeCore-<version>.jar (its archiveBaseName is EverNifeCore - note this is not a Maven coordinate; the published API artifact is evernifecore-minecraft).

minecraft/modules/* - version compatibility

These are WorldGuard and WorldEdit compatibility layers, not NMS code. They exist because those two plugins changed their API significantly across Minecraft versions, and EverNifeCore offers a single version-agnostic protection/region API on top.

• VersionedPlugins - the version-agnostic adapter interfaces (WGPlatform, WEPlatform, FCWorldGuardRegion, the WorldEdit clipboard/region wrappers) plus UnsafeUtil. It compiles against spigot-api.
• v1_7_10 / v1_12_2 / v1_16_5 - per-version implementations of those wrappers (packages compat.v1_7_R4.*, compat.v1_12_R2.*, compat.v1_16_R3.*). They touch neither net.minecraft.* nor org.bukkit.craftbukkit.*; no CraftBukkit jar is needed to build.

These four modules are compiled with plain Java 8 settings (no Jabel), set version = dont-matter, and are never published - the runtime picks the right one for the running server. The reasoning is on Version Compatibility and Java Versions & Toolchains.

hytale

The Hytale platform port - the same shape as minecraft but for the Hytale server API. It depends on common and produces its own shadow jar with the classifier Hytale:

./gradlew :hytale:shadowJar

Because Hytale has no runtime dependency loader, its shadow jar must carry everything common needs at runtime. Current state and caveats are on Hytale Platform.

libby

A fork of the Libby runtime dependency loader. On Bukkit, some libraries are downloaded at first launch rather than bundled; libby is the loader that fetches them into an isolated classloader. (Hytale does not use it - hence the bundling difference above.)

---

Where the storage layer lives

There is no storage module in this build. Player-data persistence comes from the external EveryDatabase library (everydatabase-core + -manager), declared as api dependencies of common. Its internals - entities, codecs, backends, caching - are documented in its own EveryDatabase wiki. EverNifeCore's player-data layer that sits on top of it is on PlayerData & PDSections.

---

See also

• Building from Source - JDKs, Gradle, the private flatDir dependencies.
• Architecture Overview - how the pieces talk at runtime.
• Platform Abstraction - providers and the platoverride pattern.
• Java Versions & Toolchains - the bytecode caps and toolchain.