Пробуйте Minecraft плагины легко с run-task

Если вы создали плагин для Minecraft и тестирали его локально, вы знаете этот ритуал: загрузка серверного jar, настройка директорий, размещение плагина в plugins/, запуск и ожидание инициализации. Каждый раз. run-task устраняет эту настройку с помощью одной команды Gradle, которая автоматически обрабатывает все.

Что делает run-task

run-task - это набор плагинов Gradle, автоматизирующих одну из самых утомительных частей разработки плагинов для Minecraft: интеграционное тестирование. Вместо ручной загрузки серверного ПО, его настройки и размещения скомпилированного плагина в правильной папке, вы определяете желаемую версию и запускаете команду. Плагин автоматически загружает, настраивает и запускает все.

Есть три основные варианта. run-paper работает с серверами Paper (предпочтительный выбор для большинства разработчиков), run-velocity - с прокси-софтом Velocity, а run-waterfall - с прокси Waterfall. Каждый из них работает по одному принципу: настройка一次 в вашем build.gradle.kts, затем использование простой команды для запуска тестового окружения.

Это может показаться небольшим удобством. Но когда вы итеративно работаете над плагином и проводите десятки тестов в день, экономия времени быстро накапливается.

Почему разработчики плагинов нуждаются в этом

Тестирование плагина для Minecraft принципиально отличается от тестирования обычной Java-библиотеки. Вы не можете просто запустить юнит-тесты и завершить работу. Ваш код работает внутри сервера Minecraft, взаимодействует с игровым состоянием, управляет событиями игроков и полагается на API, которые меняются между версиями. Это территория интеграционного тестирования, и от этого нельзя отойти.

Без run-task? Рабочий процесс болезненный. Загрузите Paper 1.21.8, извлеките его, создайте папку plugins, соберите jar, скопируйте его, запустите серверный скрипт, подождите запуска, подключитесь через клиент, протестируйте функцию, выключите, измените код, повторите. Повторите это пятьдесят раз во время разработки функции, и вы потеряете часы на чистую бумажную работу.

Скорость здесь имеет значение.

run-task полностью удаляет этот фрикшн. Измените код, запустите gradle runServer, и ваш плагин уже загружен через несколько секунд. Это особенно ценно при тестировании нескольких версий Minecraft - переключите версии в вашей конфигурации и повторно запустите без ручной настройки.

Начало работы с run-task

Установка проста. Добавьте плагин в ваш build.gradle.kts и укажите желаемую версию для запуска:

plugins {
 id("xyz.jpenilla.run-paper") version "3.0.2"
}

tasks {
 runServer {
 minecraftVersion("1.21.8")
 }
}

Всё, что вам нужно. run-task автоматически обнаружит скомпилированный jar вашего плагина и включит его. Если вы используете shadowJar для упаковки зависимостей, он будет использовать его вместо этого - без ручной настройки.

Чтобы запустить:

gradle runServer

Ваш сервер Paper запустится с уже загруженным плагином, готовым для тестирования. Первый запуск занимает больше времени из-за загрузки всего, но последующие запуски намного быстрее благодаря закешированным серверным файлам.

Для тестирования прокси Velocity настройка几乎 идентична:

plugins {
 id("xyz.jpenilla.run-velocity") version "3.0.2"
}

tasks {
 runVelocity {
 velocityVersion("3.4.0")
 }
}

Плагин автоматически обрабатывает совместимость версий, поэтому вы можете тестировать против релиз-кандидатов или стабильных версий без беспокойства о слоях совместимости.

Что делает run-task достойным использования

Лучшая особенность - жесткая простота. run-task не пытается быть умным - он загружает указанное серверное ПО, обнаруживает jar вашего плагина и запускает его. Меньше движущихся частей означает меньше поломок.

Автоматическое обнаружение shadowJar действительно полезно, если вы упаковываете зависимости. Многие плагины требуют затенения библиотек для пользовательских форматов данных или новых API. run-task尊重 этот момент без дополнительной настройки.

Переключение версий мертво просто.

Хотите протестировать на 1.20.4, 1.21.1 и последний снепшот? Измените одну строку и повторно запустите. Регрессионное тестирование становится намного менее болезненным. И если вы строите инструменты для администраторов серверов (как тестирование систем голосования Votifier или эксперименты с пользовательскими MOTD сервера), наличие быстрого доступа к запущенному серверу бесценно.

Одна деталь, достойная внимания: run-task尊重 структуру подпроектов Gradle. Если вы организуете код плагина через несколько модулей, он автоматически определяет правильный jar. Это менее тривиально, чем кажется.

Общие ловушки и важные моменты

Первая ловушка: run-task загружает серверное ПО в кэш .gradle - обычно ~/.gradle на Linux/Mac, %USERPROFILE%\.gradle на Windows. Если у вас мало свободного дискового пространства или慢ная связь, первый запуск занимает минуту-две. Это стоит того, но ожидайте начальную задержку.

Версия Java имеет значение.

Paper и Waterfall обычно требуют Java 21 или выше, в то время как более старые версии Velocity могут работать с Java 17. Если вы используете менеджер версий, например, sdkman, убедитесь, что активна правильная версия перед запуском.

Есть также кривая обучения синтаксису Gradle, если вы новичок в нём. run-task использует Kotlin DSL (build.gradle.kts), который более безопасен по типам, чем Groovy, но крутее для начинающих. Если вы всё ещё используете синтаксис build.gradle, конвертация обычно проста.

На самом деле, вот что сбивает людей с толку: run-task предполагает, что вы тестируете один плагин в изоляции. Если вы строите что-то, требующее запуска нескольких серверов одновременно (как настройка прокси с несколькими бэкендами), вам потребуется оркестрировать это отдельно. Это не ограничение инструмента, а его философия дизайна.

Когда run-task не является правильным выбором

run-task идеален для разработки плагинов. Это не решение для всех случаев.

Если вы строите полную серверную дистрибутив с пользовательскими конфигами, стартовыми скриптами и несколькими плагинами, вам, вероятно, больше подойдёт Docker или ручная настройка вместо run-task. run-task предполагает, что вы тестируете один плагин в изоляции.

Для интеграционного тестирования через несколько типов серверного ПО одновременно вам потребуется более сложная оркестрация - возможно, Docker Compose или пользовательский тестовый харнесс, встроенный в вашу CI/CD-последовательность.

Тяжёлое тестирование административных рабочих процессов сервера (мониторинг, резервное копирование, управление кластером) может быть лучше обеспечено полной серверной средой с правильной персистентностью, а не временными настройками run-task.

Большинство разработчиков плагинов найдут, что run-task покрывает 90% их потребностей в тестировании.