Files

T

Antone Barbaud c1b414f400 feat: SQLite persistence, default /core commands, Bukkit events, bootstrap

CRCore bootstrap class: one-line setup for game plugins (new CRCore(this).enable()).
Wires SQLite, services with event firing, and the /core command tree.

SQLite layer (fr.luc.crcore.database): Database wrapper exposing execute/update/
queryOne/query plus a fluent TableBuilder. ColumnType enum, RowMapper interface,
DatabaseException. Game plugins create their own tables in 2 lines via
db.table("foo").ifNotExists().column(...).create().

Repositories: SqliteTeamRepository and SqlitePlayerProfileRepository extend their
InMemory counterparts (write-through cache). 5 internal tables prefixed crcore_.

Command framework refactored for nested sub-commands: subcommand storage moved
from BaseCommand to AbstractCommand, recursive dispatch() and tabComplete(),
replaceSubCommand() for plugin overrides.

Default /core team commands (13 leaf sub-commands): create, delete, add, remove,
join, leave, info, list, transfer, visibility, score, top, setspawn. Each in its
own class under fr.luc.crcore.command.builtin.team, fully substitutable.

Bukkit events: 9 team events (Create/Dissolve/MemberAdd/MemberRemove/PlayerJoin/
LeadershipTransfer/VisibilityChange/ScoreChange/SpawnPointChange) + 3 player
events (ProfileCreate/Delete/ScoreChange). All post-only, non-cancellable.
BukkitEventFiringTeamServiceImpl and BukkitEventFiringPlayerProfileServiceImpl
override the on* hooks to call Bukkit.getPluginManager().callEvent.

JavaDoc on all new public classes and key existing ones. docs/, GEMINI.md and
PUML diagrams synced: new sections (built-in commands, events, database,
bootstrap), 4 new diagrams (builtin-commands, events, database, bootstrap-
sequence), and 7 new architecture decisions logged.

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

2026-06-09 10:54:00 +02:00

3.4 KiB

Raw Blame History

GEMINI.md — Instructions pour l'assistant

Source de vérité

Le dossier docs/ est la source unique de vérité du projet.

Toute spécification, règle, décision technique, commande ou contrainte doit être lue depuis docs/ et écrite dans docs/.
Avant d'implémenter, vérifier ce qui est consigné dans docs/.
Toute nouvelle information donnée par l'utilisateur va dans le fichier adapté :
- docs/features.md — domaines fonctionnels (team, player, commandes built-in, events, database)
- docs/decisions.md — décisions techniques / architecturales
- docs/setup.md — installation, build, intégration côté plugin de jeu
- docs/README.md — vue d'ensemble et index
- docs/diagrams/*.puml — diagrammes (classe / séquence / activité)
En cas de conflit code ↔ docs/, docs/ fait foi.

Nature du projet

CR-Core est une librairie Java/Maven consommée par des plugins Bukkit ("plugins de jeu"). Pas de plugin.yml côté core — c'est le plugin de jeu qui en a un et qui instancie {@code CRCore} dans son {@code onEnable()}.

Nom : CR-Core (artifactId Maven : CR-Core)
Type : librairie (jar)
Cible runtime : serveur Paper/Spigot 1.16.5
Build : Maven, Java 16
Package racine : fr.luc.crcore
SQLite : org.xerial:sqlite-jdbc (compile scope)

Domaines

fr.luc.crcore.common — abstractions partagées (Identifiable, Named, ScoreHolder, AbstractEntity, Repository<T>)
fr.luc.crcore.team — équipes : visibilité (PUBLIC/PRIVATE), membres, leader, scores nommés, classements, point de spawn. Sous-package event/ pour les évènements Bukkit.
fr.luc.crcore.player — profils joueurs : scores nommés, classements individuels. Sous-package event/.
fr.luc.crcore.command — framework de commandes (nested sub-commands, arguments typés, tab-complete). Sous-package builtin/ pour les commandes par défaut /core team ....
fr.luc.crcore.database — wrapper SQLite minimaliste (Database, TableBuilder, RowMapper).
fr.luc.crcore.CRCore — point d'entrée bootstrap (instancié en une ligne par le plugin de jeu).

Principe : simple par défaut, overridable partout

Chaque service expose des hooks protected que les plugins de jeu peuvent overrider :

factories (newTeam, newRanking, newProfile)
validations (validateName, validateJoinable, …)
post-hooks (onAfterCreate, onMemberAdded, onScoreChanged, …)

Chaque commande built-in (TeamCreateSubCommand, etc.) est elle aussi substituable par nom via replaceSubCommand(...).

Règles :

Pas de final sur les classes du noyau.
Méthodes-clés en protected (pas private).
Hooks onBefore... / onAfter... partout où ça a du sens.
Factories pour permettre les sous-classes.

Workflow attendu

Lire le contexte pertinent dans docs/.
Discuter / valider l'approche avec l'utilisateur si nécessaire.
Mettre à jour docs/ (et le .puml concerné) avec la décision ou la spec.
Implémenter le code conformément à la doc.

Conventions de code

Code (classes, méthodes, attributs, variables) en anglais standard.
Messages joueur et documentation en français.
JavaDoc en français sur les classes publiques et les méthodes non triviales.
Séparation stricte : interface, enum, abstract class, class concrète, exception — chacun dans son fichier.

3.4 KiB Raw Blame History