modèle de plugin de robinet

Modèle de plugin Spigot

Vous pouvez utiliser ce modèle pour développer facilement vos propres plugins Spigot de haute qualité à l'aide de Gradle.

Consultez le modèle de serveur Minecraft pour démarrer rapidement votre réseau Minecraft en moins de 30 secondes.

• Caractéristiques
• Configuration de démarrage rapide
• Publier une nouvelle version de votre plugin
  • Format du message de validation
• Publication de votre package maven
  • À propos du groupe et de l'artefactId
  • Authentification du package Github
• Débogage de votre plugin
  • Copiez votre plugin automatiquement
  • Exécuter et déboguer le serveur Minecraft
• Références

Caractéristiques

Le modèle ou mieux le passe-partout est livré avec de nombreuses fonctionnalités utiles si vous souhaitez développer des plugins de haute qualité. Cependant, vous n'avez pas besoin de toutes les utiliser, vous pouvez simplement supprimer les fonctionnalités dont vous n'avez pas besoin.

• Projet Gradle prêt à l'emploi avec de nombreuses tâches utilitaires
• Génération automatique de plugin.yaml basée sur les propriétés du projet avec SpiGradle
• Serveur de test Spigot intégré avec une construction en un clic, copiez le plugin et démarrez le débogage dans la tâche IntelliJ
• Plugin Gradle Shadow pour expédier facilement vos dépendances nécessaires avec votre plugin
• Exemples d'intégrations comprenant des tests pour Annotation Command Framework et Vault.
• Configuration de test JUnit 5 comprenant MockBukkit et AssertJ
• Rapport de couverture du code Jacoco comprenant une tâche de téléchargement vers codecov
• Pipeline de publication sémantique entièrement intégré
• Génération automatique du journal des modifications basée sur les messages de validation conventionnels
• Workflow d'actions Github pour la construction et la publication
• Publication d' artefacts Maven sur des packages GitHub

  plus besoin de Nexus auto-hébergé ou de serveur d'artefacts

• Modèles de problèmes GitHub pour les demandes de bogues et de fonctionnalités
• Lignes directrices en matière de contribution et de code de conduite
• Jolis badges pour montrer votre projet

Configuration de démarrage rapide

• Créez un nouveau projet Github à l'aide de ce modèle.
• Clonez le nouveau référentiel et ouvrez-le dans IntelliJ.
• Mettez à jour le fichier gradle.properties et modifiez les variables suivantes :
  • group : votre-maven-group-id (par exemple : io.github.silthus)
  • pluginName : VotrePluginName
  • author : VotreNom
• Mettez à jour le root.projectName dans settings.gradle . Ce sera votre artifactId .
• Supprimez le CHANGELOG.md . Il sera généré lors de votre première version.
• Mettez à jour le README pour qu'il pointe vers votre projet et votre identifiant de ressource spigot.
• Renommez le package Java et le plugin en fonction de votre projet.
• Ensuite, exécutez la tâche de progression prepareSpigotPlugins qui tentera de télécharger toutes les dépendances du plugin et de les placer dans debug/spigot/plugins/ .
• Démarrez le serveur Minecraft en exécutant la tâche debugPaper . Cela démarrera le serveur en arrière-plan et vous pourrez vous y connecter en utilisant l'adresse localhost:25565 .
• Codez :) - et une fois que vous êtes prêt, poussez votre commit (dans le style de commit conventionnel) vers le maître.

Veuillez lire les directives de contribution avant de soumettre des demandes d'extraction ou des problèmes d'ouverture.

NOTE
Vous devrez peut-être exécuter la tâche gradle clean après avoir renommé les packages et réimporter le projet Gradle pour résoudre les erreurs liées à la génération du plugin.yml .

Publier une nouvelle version de votre plugin

L'un des principaux avantages de ce modèle est le fait qu'il publiera automatiquement une nouvelle version à chaque poussée vers master en fonction de vos messages de validation. Cela garantit que votre plugin est publié conformément aux directives de gestion des versions sémantiques. Pour que cela fonctionne, vous devez suivre quelques règles simples :

• Validez uniquement le code fonctionnel et testé dans la branche principale. Utilisez les Pull Requests pour travailler sur des fonctionnalités plus importantes ou des corrections de bugs et fusionnez-les lorsque vous êtes prêt.
• Chaque correction de bug, fonctionnalité et modification doit être associée à un commit. Ne mélangez pas plusieurs bogues, fonctionnalités, etc. dans un seul énorme message de validation. Gardez la taille de votre engagement petite et engagez-vous souvent.
• Vos messages de validation doivent suivre les règles de validation conventionnelles.

Format du message de validation

Voir la page d'accueil des commits conventionnels pour plus de détails et d'exemples sur le sujet. Mais voici un bref résumé pour vous aider à démarrer.

La spécification Conventional Commits est une convention légère s'ajoutant aux messages de validation. Il fournit un ensemble simple de règles pour créer un historique de validation explicite ; ce qui facilite l'écriture d'outils automatisés par-dessus. Cette convention s'accorde avec SemVer, en décrivant les fonctionnalités, les correctifs et les modifications importantes apportées dans les messages de validation.

Le message de validation doit être structuré comme suit :

 [optional scope]: 

[optional body]

[optional footer(s)]

Le commit contient les éléments structurels suivants, pour communiquer l'intention aux consommateurs de votre bibliothèque ou plugin :

• fix: un commit de type fix corrige un bug dans votre base de code (cela est en corrélation avec PATCH dans le versioning sémantique).
• feat: un commit de type feat introduit une nouvelle fonctionnalité dans la base de code (cela est en corrélation avec MINOR dans le versioning sémantique).
• BREAKING CHANGE: un commit qui a un pied de page BREAKING CHANGE :, ou ajoute un ! après le type/portée, introduit un changement radical d'API (en corrélation avec MAJOR dans le versioning sémantique). Un CHANGEMENT RUPTURE peut faire partie de commits de tout type.
• les types autres que fix: et feat: sont autorisés, par exemple @commitlint/config-conventional (basé sur la convention angulaire) recommande build: , chore: , ci: , docs: , style: , refactor: , perf: , test: , et d'autres.
• des pieds de page autres que BREAKING CHANGE: peuvent être fournis et suivre une convention similaire au format git trailer. Les types supplémentaires ne sont pas obligatoires par la spécification Conventional Commits et n'ont aucun effet implicite sur la gestion des versions sémantiques (à moins qu'ils n'incluent un CHANGEMENT RUPTURE).

Une portée peut être fournie au type d'un commit, pour fournir des informations contextuelles supplémentaires et est contenue entre parenthèses, par exemple, feat(parser): add ability to parse arrays .

Voici quelques exemples :

Message de validation avec description et pied de page de changement de rupture

 feat: allow provided config object to extend other configs

BREAKING CHANGE: `extends` key in config file is now used for extending other config files

Valider un message sans corps

 docs: correct spelling of CHANGELOG

Message de validation avec portée

 feat(lang): add polish language

Message de validation avec un corps de plusieurs paragraphes et plusieurs pieds de page

 fix: correct minor typos in code

see the issue for details

on typos fixed.

Reviewed-by: Z
Refs #133

Publication de votre package maven

Votre plugin sera automatiquement publié en tant que package maven sur les packages Github dès que vous publierez une nouvelle version.

À propos du groupe et de l'artefactId

Le group ajouté par votre artifactId est utilisé pour identifier de manière unique votre projet lors de son importation dans d'autres projets. Lorsque vous importez spigot dans votre projet, vous utilisez le groupe org.spigotmc suivi de l'artefactId spigot-api et de la version.

Ce qui suit est tiré du guide de dénomination officiel de Maven.

• groupId identifie de manière unique votre projet dans tous les projets. Un ID de groupe doit suivre les règles de nom de package Java. Cela signifie que cela commence par un nom de domaine inversé que vous contrôlez. Par exemple : org.apache.maven , org.apache.commons .
  Si vous ne possédez pas de domaine, vous pouvez utiliser le domaine github io.github suivi de votre nom d'utilisateur Github, par exemple io.github.silthus
• artifactId est le nom du pot sans version. Si vous l'avez créé, vous pouvez choisir le nom de votre choix avec des lettres minuscules et aucun symbole étrange. Par exemple : `maven, commons-math

Authentification du package Github

Vous devez configurer l'authentification pour les packages Github si vous souhaitez utiliser votre package maven dans d'autres projets.

1. Créer un jeton d'accès personnel Github
2. Créez ou mettez à jour le gradle.properties dans C:Users%username%.gradle avec ce qui suit et remplacez YOUR_GITHUB_USERNAME par votre nom d'utilisateur Github et YOUR_PERSONAL_ACCESS_TOKEN par le jeton d'accès de l'étape 1.

 gpr.user =YOUR_GITHUB_USERNAME
gpr.key =YOUR_PERSONAL_ACCESS_TOKEN

Débogage de votre plugin

Copiez votre plugin automatiquement

Vous pouvez exporter votre plugin vers le répertoire plugins depuis votre répertoire de travail avec la tâche Gradle PrepareSpigotPlugins . La tâche construira et copiera automatiquement votre plugin dans le répertoire plugins/ .

Exécuter et déboguer le serveur Minecraft

Vous pouvez exécuter ou déboguer votre plugin à l'aide de la configuration d'exécution Server depuis IntelliJ pour télécharger automatiquement le serveur Minecraft, le construire, y copier vos plugins et ceux qui en dépendent et le démarrer en mode débogage.

Cela est dû à la puissance impressionnante des tâches de débogage de Spigradle. Pour en savoir plus, consultez la page Spigradle Github.

Références

• Spigradle : propose des tâches de progression impressionnantes qui vous facilitent grandement la vie
• sémantique-release : à mon avis, chaque projet devrait l'utiliser !
• messages de validation conventionnels : validez le message de la bonne manière