スピゴットプラグインテンプレート

スピゴットプラグインテンプレート

このテンプレートを使用すると、Gradle を使用して独自の高品質の Spigot プラグインを簡単に開発できます。

30 秒以内に Minecraft ネットワークを迅速に起動するには、minecraft-server-template を参照してください。

• 特徴
• クイックスタートセットアップ
• プラグインの新しいバージョンをリリースする
  • コミットメッセージのフォーマット
• Maven パッケージを公開する
  • グループとartifactIdについて
  • Github パッケージの認証
• プラグインのデバッグ
  • プラグインを自動的にコピーする
  • Minecraft サーバーの実行とデバッグ
• 参考文献

特徴

テンプレートまたはより優れたボイラープレートには、高品質のプラグインを開発したい場合に役立つ多くの機能が付属しています。ただし、すべてを使用する必要はなく、不要な機能を削除するだけで済みます。

• 多くのユーティリティ タスクを備えたすぐに使用できるGradleプロジェクト
• SpiGradle を使用したプロジェクト プロパティに基づいたplugin.yamlの自動生成
• ワンクリックでビルド、プラグインをコピーし、IntelliJ タスクでデバッグを開始できる統合されたSpigot テスト サーバー
• Gradle シャドウ プラグインにより、プラグインに必要な依存関係を簡単に配布できます。
• Annotation Command Framework と Vault のテストを含む統合の例。
• MockBukkit と AssertJ を含むJUnit 5テスト セットアップ
• codecov へのアップロードタスクを含むJacoco コードカバレッジレポート
• 完全に統合されたセマンティックリリースリリースパイプライン
• 従来のコミットメッセージに基づいた自動変更ログ生成
• ビルドとリリースのためのGithub Actionsワークフロー
• Maven アーティファクトの GitHub パッケージへの公開

  自己ホスト型ネクサスやアーティファクト サーバーはもう必要ありません

• バグおよび機能リクエスト用の GitHub問題テンプレート
• 貢献と行動規範のガイドライン
• あなたのプロジェクトを示す素敵なバッジ

クイックスタートセットアップ

• このテンプレートを使用して新しい Github プロジェクトを作成します。
• 新しいリポジトリのクローンを作成し、IntelliJ で開きます。
• gradle.propertiesファイルを更新し、次の変数を変更します。
  • group : your-maven-group-id (例: io.github.silthus)
  • pluginName : あなたのプラグイン名
  • author ：あなたの名前
• settings.gradle内のroot.projectNameを更新します。これがartifactIdになります。
• CHANGELOG.md削除します。これは最初のリリース時に生成されます。
• プロジェクトとスピゴットのリソース ID を指すようにREADME更新します。
• プロジェクトに合わせて Java パッケージとプラグインの名前を変更します。
• 次に、 prepareSpigotPlugins gradle タスクを実行します。これにより、すべてのプラグインの依存関係がダウンロードされ、 debug/spigot/plugins/に配置されます。
• debugPaperタスクを実行して、Minecraft サーバーを起動します。これによりサーバーがバックグラウンドで起動し、 localhost:25565アドレスを使用してサーバーに接続できるようになります。
• コードを離れてください:) -そして準備ができたら、コミットを (従来のコミット スタイルで) マスターにプッシュします。

プル リクエストを送信したり、問題をオープンしたりする前に、貢献ガイドラインをお読みください。

注記
plugin.yml生成時のエラーを解決するには、パッケージの名前を変更した後にgradle cleanタスクを実行し、gradle プロジェクトを再インポートする必要がある場合があります。

プラグインの新しいバージョンをリリースする

このテンプレートの主な利点の 1 つは、コミット メッセージに基づいてmasterにプッシュされるたびに新しいバージョンが自動的にリリースされるという事実です。これにより、プラグインがセマンティック バージョニング ガイドラインに従ってリリースされるようになります。これを機能させるには、いくつかの簡単なルールに従う必要があります。

• 動作しテストされたコードのみを master ブランチにコミットします。プル リクエストを使用して、より大きな機能やバグ修正に取り組み、準備ができたらそれらをマージします。
• すべてのバグ修正、機能、および変更には、1 つのコミットが関連付けられている必要があります。複数のバグや機能などを 1 つの巨大なコミット メッセージに混在させないでください。コミットのサイズを小さくし、頻繁にコミットしてください。
• コミット メッセージは従来のコミット ルールに従う必要があります。

コミットメッセージのフォーマット

このトピックの詳細と例については、従来のコミットのホームページを参照してください。ただし、始めるために簡単な概要をここに示します。

従来のコミット仕様は、コミット メッセージに基づく軽量の規約です。これは、明示的なコミット履歴を作成するための簡単なルールのセットを提供します。これにより、その上に自動ツールを簡単に作成できるようになります。この規則は、コミット メッセージで行われた機能、修正、および重大な変更を説明することにより、SemVer に適合します。

コミット メッセージは次のように構成されている必要があります。

 [optional scope]: 

[optional body]

[optional footer(s)]

コミットには、ライブラリまたはプラグインの利用者に意図を伝えるための次の構造要素が含まれています。

• fix: fix タイプのコミットは、コードベースのバグにパッチを適用します (これはセマンティック バージョニングの PATCH と相関します)。
• feat: feat タイプのコミットは、コードベースに新しい機能を導入します (これはセマンティック バージョニングの MINOR と相関します)。
• BREAKING CHANGE:フッター BREAKING CHANGE: が含まれるコミット、または ! が追加されるコミットタイプ/スコープの後に、API の重大な変更が導入されます (セマンティック バージョニングの MAJOR に関連)。 BREAKING CHANGE は、あらゆる種類のコミットの一部にすることができます。
• fix: と feat: 以外のタイプは許可されます。たとえば、 @commitlint/config-conventional (Angular 規約に基づく) では、 build: 、 chore: 、 ci: 、 docs: 、 style: 、 refactor: 、 perf: 、 test:が推奨されます。 test:など。
• BREAKING CHANGE: 以外のフッターが提供される場合があり、git トレーラー形式と同様の規則に従います。追加のタイプは従来のコミット仕様では必須ではなく、(重大な変更が含まれていない限り) セマンティック バージョニングに暗黙的な影響を及ぼしません。

追加のコンテキスト情報を提供するためにコミットのタイプにスコープを提供することができ、これは括弧内に含まれます (例: feat(parser): add ability to parse arrays )。

以下にいくつかの例を示します。

説明と重大な変更フッターを含むコミットメッセージ

 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

Maven パッケージを公開する

新しいバージョンがリリースされるとすぐに、プラグインは Github パッケージで Maven パッケージとして自動的に公開されます。

グループとartifactIdについて

artifactIdによって追加されたgroup 、プロジェクトを他のプロジェクトにインポートするときにプロジェクトを一意に識別するために使用されます。プロジェクトに spigot をインポートするときは、グループorg.spigotmcの後に artifactId spigot-apiとバージョンを使用します。

以下は、公式の Maven 命名ガイドからの抜粋です。

• groupIdすべてのプロジェクトにわたってプロジェクトを一意に識別します。グループ ID は Java のパッケージ名の規則に従う必要があります。これは、あなたが管理する逆向きのドメイン名で始まることを意味します。例: org.apache.maven 、 org.apache.commons 。
  ドメインを所有していない場合は、Github ドメインio.githubに Github ユーザー名を追加して使用できます (例: io.github.silthus
• artifactIdバージョンのない jar の名前です。自分で作成した場合は、小文字を使用し、奇妙な記号を使用せずに、任意の名前を選択できます。例: `maven、commons-math

Github パッケージの認証

Maven パッケージを他のプロジェクトで使用する場合は、Github パッケージの認証を構成する必要があります。

1. Github パーソナル アクセス トークンを作成する
2. C:Users%username%.gradle内のgradle.properties次のように作成または更新し、 YOUR_GITHUB_USERNAME Github ユーザー名に置き換え、 YOUR_PERSONAL_ACCESS_TOKENを手順 1 のアクセス トークンに置き換えます。

 gpr.user =YOUR_GITHUB_USERNAME
gpr.key =YOUR_PERSONAL_ACCESS_TOKEN

プラグインのデバッグ

プラグインを自動的にコピーする

Gradle prepareSpigotPluginsタスクを使用して、作業ディレクトリからプラグイン ディレクトリにプラグインをエクスポートできます。このタスクにより、プラグインが自動的に構築され、 plugins/ディレクトリにコピーされます。

Minecraft サーバーの実行とデバッグ

IntelliJ 内からServer実行構成を使用してプラグインを実行またはデバッグすると、Minecraft サーバーが自動的にダウンロードされ、構築され、独自のプラグインと依存プラグインがそこにコピーされ、デバッグ モードで起動されます。

これは、Spigradle のデバッグ タスクの素晴らしい能力によるものです。詳細については、Spigradle Github ページをご覧ください。

参考文献

• Spiggradle:作業をはるかに簡単にする素晴らしい Gradle タスクを提供します
• semantic-release:私の意見では、すべてのプロジェクトでこれを使用する必要があります。
• 従来のコミットメッセージ:メッセージを正しい方法でコミットする