modelo de plug-in spigot
v4.5.3
Você pode usar este modelo para desenvolver seus próprios plug-ins Spigot de alta qualidade usando Gradle com facilidade.
Consulte o minecraft-server-template para iniciar rapidamente sua rede Minecraft em menos de 30 segundos.
O modelo ou modelo melhor vem com muitos recursos que são úteis se você deseja desenvolver plug-ins de alta qualidade. No entanto, você não precisa usar todos eles, você pode simplesmente remover os recursos desnecessários.
plugin.yaml com base nas propriedades do projeto com SpiGradlenão há mais necessidade de nexo auto-hospedado ou servidor de artefato
group : seu-maven-group-id (por exemplo: io.github.silthus)pluginName : SeuPluginNameauthor : SeuNomeroot.projectName dentro de settings.gradle . Este será o seu artifactId .CHANGELOG.md . Ele será gerado em seu primeiro lançamento.README para apontar para o seu projeto e o ID do recurso spigot.prepareSpigotPlugins . Isso tentará baixar todas as dependências do plug-in e colocá-las em debug/spigot/plugins/ .debugPaper . Isso iniciará o servidor em segundo plano e você poderá se conectar a ele usando o endereço localhost:25565 .
Por favor, leia as Diretrizes de Contribuição antes de enviar qualquer solicitação pull ou abrir problemas.
OBSERVAÇÃO
Pode ser necessário executar a tarefagradle cleanapós renomear os pacotes e reimportar o projeto gradle para resolver erros na geração doplugin.yml.
Um dos principais benefícios deste modelo é o fato de que ele lançará automaticamente uma nova versão a cada push to master com base em suas mensagens de commit. Isso garante que seu plugin seja lançado seguindo as diretrizes de controle de versão semântico. Para que isso funcione, você deve seguir algumas regras simples:
Veja a página inicial do commit convencional para mais detalhes e exemplos sobre o tema. Mas aqui está um rápido resumo para você começar.
A especificação Convencional Commits é uma convenção leve sobre mensagens de commit. Ele fornece um conjunto fácil de regras para criar um histórico de commits explícito; o que torna mais fácil escrever ferramentas automatizadas. Esta convenção se encaixa com SemVer, descrevendo os recursos, correções e alterações importantes feitas nas mensagens de commit.
A mensagem de commit deve ser estruturada da seguinte forma:
[optional scope]:
[optional body]
[optional footer(s)]
O commit contém os seguintes elementos estruturais, para comunicar a intenção aos consumidores de sua biblioteca ou plugin:
fix: um commit do tipo fix corrige um bug em sua base de código (isso se correlaciona com PATCH no versionamento semântico).feat: um commit do tipo feat introduz um novo recurso na base de código (isso se correlaciona com MINOR no versionamento semântico).BREAKING CHANGE: um commit que possui um rodapé BREAKING CHANGE: ou anexa um ! após o tipo/escopo, introduz uma alteração significativa na API (correlacionada com MAJOR no controle de versão semântico). UMA BREAKING CHANGE pode fazer parte de commits de qualquer tipo.build: , chore: , ci: , docs: , style: , refactor: , perf: , test: e outros.BREAKING CHANGE: podem ser fornecidos e seguir uma convenção semelhante ao formato git trailer. Tipos adicionais não são obrigatórios pela especificação Convencional Commits e não têm efeito implícito no versionamento semântico (a menos que incluam uma BREAKING CHANGE). Um escopo pode ser fornecido para um tipo de commit, para fornecer informações contextuais adicionais e está contido entre parênteses, por exemplo, feat(parser): add ability to parse arrays .
Aqui estão alguns exemplos:
feat: allow provided config object to extend other configs
BREAKING CHANGE: `extends` key in config file is now used for extending other config files
docs: correct spelling of CHANGELOG
feat(lang): add polish language
fix: correct minor typos in code
see the issue for details
on typos fixed.
Reviewed-by: Z
Refs #133
Seu plugin será publicado automaticamente como um pacote maven nos pacotes do Github assim que você lançar uma nova versão.
O group anexado ao seu artifactId é usado para identificar exclusivamente seu projeto ao importá-lo em outros projetos. Ao importar o spigot em seu projeto, você usa o grupo org.spigotmc seguido do artefatoId spigot-api e da versão.
O seguinte foi retirado do guia oficial de nomenclatura do maven.
groupId identifica exclusivamente seu projeto em todos os projetos. Um ID de grupo deve seguir as regras de nome de pacote Java. Isso significa que começa com um nome de domínio revertido que você controla. Por exemplo: org.apache.maven , org.apache.commons .io.github anexado ao seu nome de usuário do Github, por exemplo, io.github.silthusartifactId é o nome do jar sem versão. Se você o criou, poderá escolher o nome que desejar com letras minúsculas e sem símbolos estranhos. Por exemplo: `maven, matemática comumVocê precisa configurar a autenticação para pacotes Github se quiser usar seu pacote maven em outros projetos.
gradle.properties dentro de C:Users%username%.gradle com o seguinte e substitua YOUR_GITHUB_USERNAME pelo seu nome de usuário do Github e YOUR_PERSONAL_ACCESS_TOKEN pelo token de acesso da etapa 1. gpr.user =YOUR_GITHUB_USERNAME
gpr.key =YOUR_PERSONAL_ACCESS_TOKEN Você pode exportar seu plug-in para o diretório de plug-ins de seu diretório de trabalho com a tarefa Gradle prepareSpigotPlugins . A tarefa irá construir e copiar seu plugin automaticamente para o diretório plugins/ .
Você pode executar ou depurar seu plug-in usando a configuração de execução Server no IntelliJ para baixar automaticamente o servidor Minecraft, construí-lo, copiar seus plug-ins dependentes nele e iniciá-lo no modo de depuração.
Isso se deve ao incrível poder das tarefas de depuração do Spigradle. Saiba mais na página do Spigradle no Github.
