GITHUB • DOCUMENTATION • DISCORD

Aperçu - ce que fait BileTools

BileTools surveille votre répertoire de plugins et gère les changements de cycle de vie à l'exécution, de sorte qu'une reconstruction se retrouve dans le serveur en cours d'exécution au lieu d'un redémarrage.

• Auto rechargement à chaud. Recompilez sur un jar de plugin existant et BileTools détecte automatiquement le changement de contenu.

• Hot-drop. Déposez un nouveau jar dans le répertoire des plugins et il est mis en file d'attente pour un chargement à l'exécution sans un redémarrage complet.

• Auto-déchargement. Supprimez un jar suivi et son plugin est déchargé.

• Commandes de cycle de vie. Chargez, déchargez, rechargez, installez et désinstallez manuellement depuis l'arbre de commandes /bile.

• Connaissance des dépendances. Les plugins dépendants sont déchargés et rechargés autour d'un remplacement au lieu de recharger un jar aveuglément.

• Bibliothèque de plugins locale. Chaque jar que BileTools voit est archivé par version, et le même dossier est ce que /bile install lit. La sauvegarde et le retour en arrière sont la même fonctionnalité.

• Déploiement à distance. Poussez les changements de jar sélectionnés vers d'autres serveurs configurés via un transfert authentifié, limité en taille, vérifié par SHA-256.

Détection, en bref : un changement de taille ou d'horodatage ne réveille que le surveillant. Un SHA-256 du jar décide si quelque chose doit réellement être rechargé, donc un jar que vous avez touché mais que vous n'avez pas changé est ignoré.

BileTools est un outil de développement. Il manipule délibérément l'état du cycle de vie des plugins à l'exécution. C'est exactement ce qui rend la boucle de développement rapide, et c'est exactement pourquoi il appartient aux serveurs de développement et de test. Le rechargement à chaud n'est pas un substitut à un redémarrage propre sur un serveur en direct.

Compatibilité - environnements d'exécution et Java

Un jar couvre tous les six environnements d'exécution, Minecraft 1.20.1 à 26.x.

• Paper se charge via le PluginManager public du serveur

• Purpur mêmes chemins de chargement et de déchargement de la famille Paper

• Leaf fork de la famille Paper, traité comme Paper

• Folia planification régionalisée, BileTools déclare pris en charge par folia

• Canvas fork Folia, mêmes règles régionalisées

• Spigot se charge via plugin.yml; les jars qui expédient uniquement paper-plugin.yml sont refusés

Java: Java 17 pour Minecraft 1.20.1+, Java 25 pour 26.x+. Correspond à ce que votre serveur exige déjà.

Folia et Canvas: le rechargement à chaud sur des serveurs régionalisés est intrinsèquement plus fragile. Un plugin tiers qui ne déclare pas le support folia peut toujours échouer lors du chargement à chaud.

Commandes et permissions

La commande racine est /biletools. Alias : /bile, /bi, /b.

/bile load <plugin>                  Charge un jar de plugin depuis le répertoire des plugins
/bile unload <plugin>                Décharge un plugin installé
/bile reload <plugin>                Recharge un plugin installé
/bile uninstall <plugin>             Supprime un jar de plugin du répertoire des plugins
/bile install <plugin> [version=..]  Installe un plugin depuis la bibliothèque BileTools
/bile library [plugin=..]            Liste les plugins de la bibliothèque, ou les versions pour un plugin

Une permission couvre tout l'arbre :

Les commandes manuelles contournent toujours les filtres du surveillant. La complétion par tabulation suggère les plugins installés, les plugins de la bibliothèque et les versions stockées. Exécuter /bile tout seul ouvre un menu d'aide paginé avec survol et clic.

Les arguments optionnels doivent être nommés. Les passer par position échoue avec "argument inattendu" :

/bile install MyPlugin                   fonctionne  (par défaut version=latest)
/bile install MyPlugin version=1.4.2      fonctionne
/bile install MyPlugin version=latest      fonctionne
/bile install MyPlugin 1.4.2                ÉCHOUE
/bile library                             fonctionne  (liste tout)
/bile library plugin=MyPlugin              fonctionne
/bile library MyPlugin                      ÉCHOUE

Configuration - configuration par défaut complète config.yml

remote-deploy:
  slave:
    slave-enabled: false
    slave-port: 9876
    slave-payload: pickapassword
  master:
    master-enabled: false
    master-deploy-to:
    - yourserver.com:9876:password
    master-deploy-signatures:
    - MyPlugin
    - AnotherPlugin
  socket-timeout-ms: 15000
  max-transfer-bytes: 268435456
archive-plugins: true
watcher:
  idle-poll-ticks: 20
  active-poll-ticks: 5
  fingerprint-debounce-ticks: 8
  ignore:
  - LuckPerms
  - Vault
  - ProtocolLib
  - packetevents
  - WorldGuard
  - CoreProtect
  - spark
  only: []
  coalesce-window-ticks: 10
observability:
  log-timings: true
lifecycle:
  health-check: true

• watcher.ignore Noms de plugins que le chargement automatique, le rechargement et le déchargement ignoreront. Les valeurs par défaut sont des choses qui sont généralement dangereuses ou inutiles à recharger automatiquement sur une boîte de développement.

• watcher.only Lorsque cette liste n'est pas vide, seulement ces plugins sont gérés automatiquement. Utile lorsque vous développez activement un ou deux projets sur un serveur occupé.

• watcher.active-poll-ticks / idle-poll-ticks À quelle fréquence le surveillant scanne pendant que des changements arrivent, par rapport à une fois que le répertoire s'est stabilisé.

• watcher.fingerprint-debounce-ticks Combien de temps l'empreinte d'un jar doit rester stable avant que le travail de cycle de vie commence. C'est ce qui empêche les jars à moitié écrits d'être chargés.

• watcher.coalesce-window-ticks Regroupe les écritures de jar à proximité en un flush de rechargement ordonné par dépendance, de sorte qu'une construction multi-module ne déclenche pas cinq rechargements séparés.

• archive-plugins Archive chaque jar de plugin dans le dossier de la bibliothèque avant qu'il ne soit remplacé.

• lifecycle.health-check Après un chargement ou un rechargement, vérifiez que le plugin est effectivement enregistré et activé. Une opération échouée marque le plugin comme sale et suspend les rechargements automatiques pour celui-ci.

• observability.log-timings Enregistre les temps par phase (déchargement, dépendants, chargement, santé) pour chaque opération.

Bibliothèque de plugins et retour en arrière

plugins/BileTools/library/<PluginName>/<version>.jar

Avec archive-plugins activé, chaque jar de plugin que BileTools voit est copié ici avant d'être remplacé. Cela signifie que la bibliothèque double comme un historique de retour en arrière, /bile library liste ce que vous avez, et /bile install <plugin> version=<version> remet n'importe lequel d'entre eux dans le serveur en cours d'exécution.

Déploiement à distance

Optionnel. Permet à un serveur maître de pousser des changements de jar sélectionnés vers un ou plusieurs serveurs esclaves.

• Sur chaque serveur récepteur : définissez remote-deploy.slave.slave-enabled: true, choisissez un port et définissez slave-payload sur un mot de passe partagé.

• Sur le serveur d'envoi : définissez remote-deploy.master.master-enabled: true, listez chaque cible dans master-deploy-to sous la forme ci-dessous, et listez quels plugins transférer dans master-deploy-signatures.

master-deploy-to:
- host:port:password

Les transferts atterrissent dans un fichier temporaire .part et ne sont promus qu'après que le mot de passe, le nom de fichier, la taille du transfert et le SHA-256 ont tous été vérifiés. Les noms de fichiers sont assainis et tout chemin qui pourrait échapper au dossier des plugins est rejeté. Les valeurs par défaut sont une limite de 256 Mo et un délai d'attente de socket de 15 secondes.

Langues - tous les 17 codes de langue

L'anglais est sélectionné par défaut. Pour changer, définissez locale dans plugins/BileTools/language.yml :

locale: en_US

de_DE    Allemand (Allemagne)
es_ES    Espagnol (Espagne)
fi_FI    Finnois (Finlande)
fr_FR    Français (France)
he_IL    Hébreu (Israël)
it_IT    Italien (Italie)
ja-JP    Japonais (Japon)
ko_KR    Coréen (Corée du Sud)
lt_LT    Lituanien (Lituanie)
nl_NL    Néerlandais (Pays-Bas)
pl_PL    Polonais (Pologne)
pt_PT    Portugais (Portugal)
ru_RU    Russe (Russie)
tr_TR    Turc (Turquie)
vi_VI    Vietnamien (Vietnam)
zh_CN    Chinois (Simplifié)
zh_TW    Chinois (Traditionnel)

Vous pouvez également remplacer des lignes individuelles sans toucher aux bundles. Tout ce que vous ajoutez sous une section messages: dans language.yml l'emporte ; tout ce que vous laissez de côté revient à la langue sélectionnée, puis à l'anglais. Le fichier est chargé à chaud lors de l'enregistrement.

Comment un rechargement s'exécute réellement

Chaque opération rechargement à chaud, rechargement, installation, désinstallation, déploiement à distance : passe par une seule file d'attente sérialisée avec des clés de dé-duplication, sur un thread d'opérations de plugin dédié. Les mutations de cycle de vie elles-mêmes s'exécutent toujours sur le thread global ou principal.

detect -> stabiliser -> empreinte -> file d'attente -> décharger -> charger -> dépendants -> vérification de la santé

Les plugins qui implémentent le contrat ReloadAware de VolmLib reçoivent un rappel HOT_RELOAD ou HOT_UNLOAD avant que leurs tâches soient annulées et que les écouteurs soient démontés, afin qu'ils puissent vider le travail en cours pendant que leur planificateur est encore actif.

Le déchargement nettoie le plugin du graphe de commandes en direct, des services, des canaux de messagerie et des tables de recherche avant de fermer son classloader, c'est pourquoi les commandes et la complétion par tabulation reviennent correctes au lieu d'être à moitié câblées.

Les attentes de cycle de vie portent un délai d'attente explicite. Une opération bloquée apparaît comme un échec et marque le plugin comme sale plutôt que de bloquer la file d'attente. Activez observability.log-timings pour voir les temps par phase pour chaque opération.

Limites connues du rechargement à chaud

Tous les plugins ne peuvent pas être rechargés à chaud proprement, et BileTools ne fait pas semblant autrement. Les choses qui ne survivent généralement pas à un rechargement de classe :

• État statique champs conservés lors d'un rechargement de classe

• Threads d'arrière-plan travail démarré en dehors du planificateur de plugins

• Ressources natives tout ce qui est lié en dehors de la JVM

• Connexions externes sockets et pools avec leur propre durée de vie

• Internes spécifiques au plugin caches et registres appartenant à d'autres plugins

Gardez les plugins critiques ou obscurs dans la liste d'ignorés, activez les journaux de temps pendant que vous itérez, et lorsque l'état ne peut pas être reconstruit en toute sécurité, redémarrez le serveur.