plantilla de complemento de grifo

Plantilla de complemento Spigot

Puede utilizar esta plantilla para desarrollar sus propios complementos Spigot de alta calidad utilizando Gradle con facilidad.

Consulte la plantilla del servidor de Minecraft para iniciar rápidamente su red de Minecraft en menos de 30 segundos.

• Características
• Configuración de inicio rápido
• Lanzando una nueva versión de su complemento
  • Confirmar formato de mensaje
• Publicando su paquete maven
  • Acerca del grupo y el artefactoId
  • Autenticación del paquete Github
• Depurando su complemento
  • Copia tu complemento automáticamente
  • Ejecutando y depurando el servidor de Minecraft
• Referencias

Características

La plantilla o mejor modelo estándar viene con muchas características que son útiles si desea desarrollar complementos de alta calidad. Sin embargo, no es necesario utilizarlas todas, simplemente puede eliminar las funciones que no necesita.

• Proyecto Gradle listo para usar con muchas tareas de utilidad
• Generación automática de plugin.yaml basado en las propiedades del proyecto con SpiGradle
• Servidor de prueba Spigot integrado con un solo clic para compilar, copiar el complemento y comenzar a depurar en la tarea IntelliJ
• Complemento Gradle Shadow para enviar fácilmente las dependencias necesarias con su complemento
• Integraciones de ejemplo que incluyen pruebas para Annotation Command Framework y Vault.
• Configuración de prueba JUnit 5 que incluye MockBukkit y AssertJ
• Informe de cobertura del código de Jacoco que incluye una tarea de carga en codecov
• Canal de lanzamiento de lanzamiento semántico totalmente integrado
• Generación automática de registros de cambios basada en mensajes de confirmación convencionales.
• Flujo de trabajo de Github Actions para compilación y lanzamiento
• Publicación de artefactos maven en paquetes GitHub

  ya no es necesario un nexo autohospedado o un servidor artefacto

• Plantillas de problemas de GitHub para solicitudes de errores y funciones
• Pautas de contribución y código de conducta
• Bonitas insignias para mostrar tu proyecto.

Configuración de inicio rápido

• Cree un nuevo proyecto de Github usando esta plantilla.
• Clona el nuevo repositorio y ábrelo en IntelliJ.
• Actualice el archivo gradle.properties y cambie las siguientes variables:
  • group : su-id-de-grupo-maven (por ejemplo: io.github.silthus)
  • pluginName : Su nombre del complemento
  • author : TuNombre
• Actualice root.projectName dentro de settings.gradle . Este será su artifactId .
• Elimine CHANGELOG.md . Se generará en su primera versión.
• Actualice el README para que apunte a su proyecto y a la identificación del recurso.
• Cambie el nombre del paquete java y del complemento para que coincidan con su proyecto.
• Luego ejecute la tarea gradle prepareSpigotPlugins . Esto intentará descargar todas las dependencias de complementos y las colocará en debug/spigot/plugins/ .
• Inicie el servidor de Minecraft ejecutando la tarea debugPaper . Esto iniciará el servidor en segundo plano y podrá conectarse a él utilizando la dirección localhost:25565 .
• Codifique :) - y una vez que esté listo, envíe su confirmación (en el estilo de confirmación convencional) a master.

Lea las Pautas de contribución antes de enviar cualquier solicitud de extracción o abrir problemas.

NOTA
Es posible que deba ejecutar la tarea gradle clean después de cambiar el nombre de los paquetes y volver a importar el proyecto de Gradle para resolver errores al generar el plugin.yml .

Lanzando una nueva versión de su complemento

Uno de los principales beneficios de esta plantilla es el hecho de que lanzará automáticamente una nueva versión cada vez que se envíe a master en función de sus mensajes de confirmación. Esto garantiza que su complemento se publique siguiendo las pautas de control de versiones semánticas. Para que esto funcione debes seguir algunas reglas simples:

• Confirme solo código funcional y probado en la rama maestra. Utilice solicitudes de extracción para trabajar en funciones más importantes o correcciones de errores y combínelas cuando esté listo.
• Cada corrección de errores, característica y cambio debe tener una confirmación asociada. No mezcle varios errores, características, etc. en un mensaje de confirmación enorme. Mantenga el tamaño de su compromiso pequeño y comprométase con frecuencia.
• Sus mensajes de confirmación deben seguir las reglas de confirmación convencionales.

Confirmar formato de mensaje

Consulte la página de inicio de confirmación convencional para obtener más detalles y ejemplos sobre el tema. Pero aquí hay un resumen rápido para comenzar.

La especificación de confirmaciones convencionales es una convención ligera además de los mensajes de confirmación. Proporciona un conjunto sencillo de reglas para crear un historial de confirmaciones explícito; lo que facilita la escritura de herramientas automatizadas encima. Esta convención encaja con SemVer al describir las características, correcciones y cambios importantes realizados en los mensajes de confirmación.

El mensaje de confirmación debe estructurarse de la siguiente manera:

 [optional scope]: 

[optional body]

[optional footer(s)]

La confirmación contiene los siguientes elementos estructurales para comunicar la intención a los consumidores de su biblioteca o complemento:

• fix: una confirmación del tipo corrección corrige un error en su código base (esto se correlaciona con PATCH en el control de versiones semántico).
• feat: una confirmación del tipo hazaña introduce una nueva característica en el código base (esto se correlaciona con MINOR en el control de versiones semántico).
• BREAKING CHANGE: una confirmación que tiene un pie de página CAMBIO ÚLTIMO: o agrega un! después del tipo/alcance, introduce un cambio importante en la API (que se correlaciona con MAJOR en el control de versiones semántico). UN CAMBIO ÚLTIMO puede ser parte de confirmaciones de cualquier tipo.
• Se permiten tipos distintos de fix: y feat:, por ejemplo @commitlint/config-conventional (basado en la convención Angular) recomienda build: , chore: , ci: , docs: , style: , refactor: , perf: , test: y otros.
• Se pueden proporcionar pies de página distintos del BREAKING CHANGE: y seguir una convención similar al formato git trailer. La especificación de confirmaciones convencionales no exige tipos adicionales y no tienen ningún efecto implícito en el control de versiones semántico (a menos que incluyan un CAMBIO ÚLTIMO).

Se puede proporcionar un alcance al tipo de confirmación, para proporcionar información contextual adicional, y está contenido entre paréntesis, por ejemplo, feat(parser): add ability to parse arrays .

A continuación se muestran algunos ejemplos:

Mensaje de confirmación con descripción y pie de página de cambios importantes

 feat: allow provided config object to extend other configs

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

Confirmar mensaje sin cuerpo

 docs: correct spelling of CHANGELOG

Confirmar mensaje con alcance

 feat(lang): add polish language

Confirmar mensaje con cuerpo de varios párrafos y varios pies de página

 fix: correct minor typos in code

see the issue for details

on typos fixed.

Reviewed-by: Z
Refs #133

Publicando su paquete maven

Su complemento se publicará automáticamente como un paquete maven en los paquetes de Github tan pronto como publique una nueva versión.

Acerca del grupo y el artefactoId

El group agregado por su artifactId se utiliza para identificar de forma única su proyecto al importarlo en otros proyectos. Cuando importa spigot en su proyecto, utiliza el grupo org.spigotmc seguido del artefactoId spigot-api y la versión.

Lo siguiente fue tomado de la guía oficial de nombres de Maven.

• groupId identifica de forma única su proyecto en todos los proyectos. Un ID de grupo debe seguir las reglas de nombres de paquetes de Java. Esto significa que comienza con un nombre de dominio invertido que usted controla. Por ejemplo: org.apache.maven , org.apache.commons .
  Si no posee un dominio, puede usar el dominio de github io.github adjunto a su nombre de usuario de Github, por ejemplo, io.github.silthus
• artifactId es el nombre del jar sin versión. Si lo creaste, puedes elegir el nombre que quieras con letras minúsculas y sin símbolos extraños. Por ejemplo: `maven, commons-math

Autenticación del paquete Github

Debe configurar la autenticación para los paquetes Github si desea utilizar su paquete maven en otros proyectos.

1. Crear un token de acceso personal de Github
2. Cree o actualice gradle.properties dentro de C:Users%username%.gradle con lo siguiente y reemplace YOUR_GITHUB_USERNAME con su nombre de usuario de Github y YOUR_PERSONAL_ACCESS_TOKEN con el token de acceso del paso 1.

 gpr.user =YOUR_GITHUB_USERNAME
gpr.key =YOUR_PERSONAL_ACCESS_TOKEN

Depurando su complemento

Copia tu complemento automáticamente

Puede exportar su complemento al directorio de complementos desde su directorio de trabajo con la tarea Gradle prepareSpigotPlugins . La tarea creará y copiará su complemento automáticamente en el directorio plugins/ .

Ejecutando y depurando el servidor de Minecraft

Puede ejecutar o depurar su complemento utilizando la configuración de ejecución Server desde IntelliJ para descargar automáticamente el servidor de Minecraft, crearlo, copiar sus complementos y los dependientes en él e iniciarlo en modo de depuración.

Esto se debe al asombroso poder de las tareas de depuración de Spigradle. Obtenga más información en la página de Spigradle Github.

Referencias

• Spigradle: proporciona increíbles tareas de gradle que hacen tu vida mucho más fácil
• liberación semántica: en mi opinión, ¡todos los proyectos deberían usar esto!
• mensajes de confirmación convencionales: envíe el mensaje de confirmación de la manera correcta