Files

T

Antone Barbaud 84735221f1 refactor: split util/ vs features/ + modular opt-in setupX() config

Package restructure to prepare future modularization. Three layers now:

1. fr.luc.crcore.util.* (always active)
   - common, command framework, database, message, broadcast, gui,
     placeholder

2. fr.luc.crcore.features.* (opt-in)
   - team (entities, services, repos, events, exceptions, config + GUI,
     command/Team*SubCommand)
   - player (profile, ranking, services, repos, events, exceptions)

3. fr.luc.crcore.builtin.*
   - CoreCommand + CoreReloadSubCommand (top-level routing — not a
     feature, not an util)

FQN moves (game plugins importing these need their imports updated):
- fr.luc.crcore.common.*          → fr.luc.crcore.util.common.*
- fr.luc.crcore.command.*         → fr.luc.crcore.util.command.*
- fr.luc.crcore.command.builtin.team.*
                                  → fr.luc.crcore.features.team.command.*
- fr.luc.crcore.command.builtin.CoreCommand / CoreReloadSubCommand
                                  → fr.luc.crcore.builtin.*
- fr.luc.crcore.database.*        → fr.luc.crcore.util.database.*
- fr.luc.crcore.message.*         → fr.luc.crcore.util.message.*
- fr.luc.crcore.broadcast.*       → fr.luc.crcore.util.broadcast.*
- fr.luc.crcore.gui.*             → fr.luc.crcore.util.gui.*
- fr.luc.crcore.placeholder.*     → fr.luc.crcore.util.placeholder.*
- fr.luc.crcore.team.*            → fr.luc.crcore.features.team.*
- fr.luc.crcore.player.*          → fr.luc.crcore.features.player.*

CRCoreConfig — features opt-in via fluent setup:
- setupTeams()        enables team feature
- setupPlayers()      enables player feature
- setupPlaceholders() enables PAPI integration
- setupAll()          shortcut
By default no feature is active. Game plugin must opt-in.

CRCore.enable() now conditional:
- Util services always built (messages, broadcasts, gui listener).
- Team services + repos + config built only if setupTeams().
- Player services + repos built only if setupPlayers().
- Placeholder hook registered only if setupPlaceholders() (and PAPI
  installed at runtime).
- Getters of disabled features throw IllegalStateException with a clear
  message pointing to the missing setupX() call.
- CoreCommand only registers TeamGroupSubCommand if teamService and
  teamConfig are non-null. CoreReloadSubCommand handles teamConfig=null
  (just skips that reload). /core reload always available.

Docs:
- setup.md tree fully rewritten to reflect util/+features/+builtin
  layout (~70 lines of arborescence).
- setup.md code snippet shows the three opt-in patterns (setupAll /
  granular / with options).
- decisions.md logs both decisions (restructure + modular setup).
- All .puml diagrams auto-updated to new FQNs.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

2026-06-10 12:00:00 +02:00

diagrams

refactor: split util/ vs features/ + modular opt-in setupX() config

2026-06-10 12:00:00 +02:00

decisions.md

refactor: split util/ vs features/ + modular opt-in setupX() config

2026-06-10 12:00:00 +02:00

features.md

feat: typed team settings (cascade per-team → global → default) + in-game GUI

2026-06-10 11:46:51 +02:00

README.md

feat: typed team settings (cascade per-team → global → default) + in-game GUI

2026-06-10 11:46:51 +02:00

setup.md

refactor: split util/ vs features/ + modular opt-in setupX() config

2026-06-10 12:00:00 +02:00

README.md

Documentation CR-Core

Ce dossier est la source de vérité du projet. Toutes les décisions, idées, mécaniques, règles et spécifications du noyau sont consignées ici.

Objectif du projet

CR-Core est une librairie Maven réutilisable pour construire des plugins Minecraft Paper 1.16.5. Elle fournit, prêt à l'emploi en une ligne d'initialisation côté plugin de jeu :

Abstractions communes — Identifiable, Named, ScoreHolder, AbstractEntity, Repository<T>.
Domaine Team — équipes (nom, tag, couleur, chef, membres, visibilité PUBLIC/PRIVATE, scores nommés, classements, point de spawn), service overridable, exceptions dédiées.
Domaine Player — profils joueurs (scores nommés, classements individuels), service auto-créant les profils à la demande.
Framework de commandes — BaseCommand / SubCommand imbriqués, arguments typés, tab-complétion, permissions, player-only.
Commandes par défaut — /core team [create|delete|add|remove|join| leave|info|list|transfer|visibility|score|top|setspawn] fonctionnelles out-of-the-box, chacune substituable par sous-classe.
Évènements Bukkit — 9 events team + 3 events player, à écouter avec @EventHandler côté plugin de jeu.
Persistance SQLite — wrapper Database + TableBuilder fluide, repositories SQLite write-through, table custom en 2 lignes pour les plugins downstream.
Messages externalisés — MessagesService charge un seul fichier YAML <plugin>-messages.yml dans le dataFolder du plugin de jeu, avec defaults CR-Core en fallback. L'admin édite un seul fichier, placeholders nommés, codes couleur & natifs.
Broadcasts configurables — BroadcastService route chaque event CR-Core vers une liste d'audiences (NONE, LEADER, TEAM, ADMIN, ALL) définie dans <plugin>-broadcasts.yml. Séparation routes / templates. Un listener interne wire les 12 events natifs ; les game plugins peuvent broadcast leurs propres events. /core reload recharge les deux fichiers à chaud.
Paramètres d'équipe — TeamConfigService typé avec cascade per-team → global → default. 8 settings standards (FRIENDLY_FIRE, MAX_SIZE, etc.), étendable. Globaux dans <plugin>-team-config.yml, per-team en SQLite. GUI in-game via /core team settings [team].
Framework GUI — AbstractInventoryGui + GuiListener réutilisable pour tout GUI custom. Détection par holder, clic toujours annulé, GuiItems builder fluide avec codes couleur &.
Bootstrap unique — new CRCore(this).enable() dans le onEnable() du plugin de jeu, et tout est branché.

Structure de la documentation

README.md — Ce fichier. Vue d'ensemble et index.
setup.md — Build, intégration dans un plugin de jeu, exemple d'usage.
features.md — Domaines fonctionnels détaillés.
decisions.md — Journal des décisions importantes (ADR léger).
diagrams/ — Diagrammes PlantUML (.puml).

Diagrammes

Fichier	Type	Sujet
team-class-diagram.puml	Classe	Domaine Team + abstractions communes
team-create-sequence.puml	Séquence	Création d'une équipe via la commande
team-join-sequence.puml	Séquence	Auto-join sur une équipe publique
team-create-activity.puml	Activité	Flux de validation à la création
player-class-diagram.puml	Classe	Domaine Player + scores joueur
command-class-diagram.puml	Classe	Framework de commandes (nested)
builtin-commands-diagram.puml	Classe	Arbre des commandes `/core team ...`
events-diagram.puml	Classe	Évènements Bukkit team + player
database-diagram.puml	Classe	Wrapper SQLite + table builder
messages-class-diagram.puml	Classe	Service de messages YAML
broadcasts-class-diagram.puml	Classe	Service de broadcasts YAML + listener
team-config-class-diagram.puml	Classe	Paramètres d'équipe (cascade + GUI)
gui-class-diagram.puml	Classe	Framework GUI réutilisable
bootstrap-sequence.puml	Séquence	`CRCore.enable()` côté plugin de jeu

Conventions

Code : anglais standard, séparation stricte interfaces / enums / classes abstraites / classes concrètes / exceptions.
Doc & messages joueur : français.
JavaDoc en français sur les classes publiques et méthodes non triviales.
Package racine : fr.luc.crcore.
Classes du noyau non-final, méthodes-clés protected, hooks onBefore…/onAfter… et factories new… pour l'override.

Contribuer à la doc

Chaque nouvelle idée, règle, commande ou contrainte discutée doit être ajoutée au fichier approprié, avant ou pendant l'implémentation. La doc précède le code.