Менеджер проектов#
Для запуска используйте manage.cmd в Windows или ./manage.sh в Linux.
Используется для расширенного управления проектами в случае если не хватает ярлыков.
Выполняйте команды из каталога GSF CLI. В справке ниже показан manage.sh; в PowerShell используйте .\manage.cmd с
теми же аргументами. Общие параметры проекта ставятся перед командой:
./manage.sh -p main build --build-appsrc --skip-publication
.\manage.cmd -p main build --build-appsrc --skip-publication
-p выбирает конкретный проект, --all выполняет действие для всех зарегистрированных проектов. Без них нужен активный
проект. Если одновременно указаны -p и --all, используется --all; не смешивайте эти варианты.
Обычный build включает удалённую публикацию. Для локального результата используйте --skip-publication. Пошаговая
подготовка окружения находится в главах Linux и Windows.
Commands:#
usage: manage.sh [-h] [-p P] [--all] cmd ...
positional arguments:
cmd Команды
full_help Распечатать справку
version Показать версию gsf-cli
prepare_project Подготовить проект к работе
refresh_server Обновить сервер приложения
refresh_app_server Обновить только сервер приложения (без sbt-плагина)
refresh_sbt_plugin Обновить sbt-плагин
refresh_source Обновить исходный код
refresh_links Обновить ярлыки
refresh Обновить зависимости
init_project Инициализировать проект проекта
configure_idea Настроить idea
set_is_publish_release
Установить признак публикации релиза
publish_build_kit Публикация комплекта сборки
create_build_kit_release
Выпускает релиз комплекта сборки
git_branch_build_kit
Создаёт ветку для патча комплекта сборки
publish Опубликовать
publish_sbt_plugin Опубликовать sbt plugin
build Собрать проект
test Запустить юнит тесты
clean Очистить
update_module_dependency
Обновление зависимостей модулей
save_external_dependencies
Сохраняет набор всех внешних зависимостей решения в файл
diff_external_dependencies
Сравнивает набор внешних зависимостей из файла с текущими от проекта
upload_base_source_kit
Выгрузить baseSourceKit
load_base_source_kit
Загрузить baseSourceKit
options:
-h, --help show this help message and exit
-p P Имя проекта
--all Выполнить действие для всех проектов
Full_help#
usage: manage.sh full_help [-h]
options:
-h, --help show this help message and exit
Version#
usage: manage.sh version [-h]
Печатает версию gsf-cli
options:
-h, --help show this help message and exit
Prepare_project#
Сценарий подготовки рабочего места с IDEA: получает исходники и модули, формирует окружение, загружает сервер и плагин,
создаёт ярлыки и помогает настроить IDE. Может задавать вопросы. Для headless-сборки после load_config используйте
refresh и build, без этого мастера.
usage: manage.sh prepare_project [-h]
Подготавливает проект к работе, загружает сервер приложения, исходный кода, а так же конфигурирует idea
options:
-h, --help show this help message and exit
Refresh_server#
В текущей реализации вызывает то же обновление сервера, что и refresh_app_server. При необходимости запускает мастер
настройки источника. SBT-плагин отдельно обновляется командой refresh_sbt_plugin.
usage: manage.sh refresh_server [-h]
Обновляет сервер приложение
options:
-h, --help show this help message and exit
Refresh_app_server#
usage: manage.sh refresh_app_server [-h]
Обновляет только сервер приложения из настроенного источника. Без обновления sbt-плагина и исходного кода.
options:
-h, --help show this help message and exit
Refresh_sbt_plugin#
usage: manage.sh refresh_sbt_plugin [-h]
Обновляет sbt-плагин
options:
-h, --help show this help message and exit
Refresh_source#
Обновляет Git-репозиторий конфигурационного проекта и исходные модули. При первом запуске клонирует недостающие репозитории. Артефакты сервера и внешние SBT-зависимости этим действием не обновляются.
usage: manage.sh refresh_source [-h]
Обновляет исходный код проекта, при необходимости делает checkout проекта
options:
-h, --help show this help message and exit
Refresh_links#
usage: manage.sh refresh_links [-h]
Обновляет ярлыки
options:
-h, --help show this help message and exit
Refresh#
Для SBT-проекта обновляет конфигурационный Git-репозиторий и модули, скрипты окружения, сервер и SBT-плагин. Затем
выполняет update, updateClassifiers и publishDevDependencies. Если изменился сервер, может предварительно вызвать
sbt clean.
Это основной шаг после загрузки config.json. Он ещё не формирует готовые applib и appsrc — для этого выполните
build.
usage: manage.sh refresh [-h]
Обновляет зависимости
options:
-h, --help show this help message and exit
Init_project#
Для SBT выполняет подготовку dev-зависимостей и BSP через ярлыки проекта. Это не создание проекта из пустого каталога: проект должен быть зарегистрирован, а необходимые исходники, окружение и ярлыки — подготовлены.
usage: manage.sh init_project [-h]
Инициализация проекта, создание необходимых файлов перед запуском idea
options:
-h, --help show this help message and exit
Configure_idea#
usage: manage.sh configure_idea [-h]
Конфигурация idea.
При этом происходит:
Создание конфигурации для запуска сервера приложения;
Настройка для проектов системы контроля версий.
Смотри Intellij Idea: Settings > Version Control > Directory mappings
options:
-h, --help show this help message and exit
Set_is_publish_release#
usage: manage.sh set_is_publish_release [-h]
Вызывает мастера установки признака публикации релиза.
В случае если признак установлен публикация происходит по версии
заданной в конфигурации проекта.
options:
-h, --help show this help message and exit
Publish_build_kit#
usage: manage.sh publish_build_kit [-h] [-pt {release,snapshot}] [--publish-source-kit | --no-publish-source-kit]
Публикация комплекта сборки.
Версия берётся из конфигурации проекта.
options:
-h, --help show this help message and exit
-pt, --publish_type {release,snapshot}
Тип публикации комплекта сборки. Если не указан, то значение возьмётся из конфига.
--publish-source-kit, --no-publish-source-kit
Опубликовать исходники комплекта сборки
Create_build_kit_release#
usage: manage.sh create_build_kit_release [-h]
[-rt {generation,major,minor,build,patch}]
Выпускает релиз комплекта сборки.
Обрабатывается версии для корректного отображения в тегах
- Увеличивается выбранная версия и билд
- Происходит создание тега по текущей версии комплекта сборки
- Происходит commit и push изменений и тега
- Нельзя создать релиз от патча, если выбранная версия не является патчем
options:
-h, --help show this help message and exit
-rt {generation,major,minor,build,patch}, --release_type {generation,major,minor,build,patch}
Версия релиза комплекта сборки
Git_branch_build_kit#
usage: manage.sh git_branch_build_kit [-h]
Создаёт ветку для патча комплекта сборки.
При этом:
- Создаётся новая ветка, если её нет
- Локальная ревизия устанавливается в ветку с патчем
- Ошибка, если в project.yaml есть незакомиченные изменения
options:
-h, --help show this help message and exit
Publish#
usage: manage.sh publish [-h]
Опубликовать комплект сборки
options:
-h, --help show this help message and exit
Publish_sbt_plugin#
usage: manage.sh publish_sbt_plugin [-h]
Опубликовать sbt plugin из комплекта сборки
options:
-h, --help show this help message and exit
Build#
Для SBT сначала обновляет исходники, модули и конфигурацию, затем сервер и плагин. Выполняет update, компиляцию
прикладного и тестового кода, формирует applib, а с --build-appsrc также appsrc. Компиляция тестов в build не
означает их запуск.
usage: manage.sh build [-h] [--skip-publication | --no-skip-publication]
[--build-appsrc] [--publish-path ROOT]
Выполняет обновление сервера, плагина, компиляцию и публикацию
options:
-h, --help show this help message and exit
--skip-publication, --no-skip-publication
Не публиковать
--build-appsrc Дополнительно собрать appsrc
--publish-path, -P ROOT
Корневой каталог для applib и appsrc
--build-appsrc после publishLibFolder выполняет SBT-задачу publishSrcFolder. Без
--publish-path каталоги создаются в application/build/publish/applib и
application/build/publish/appsrc. При --publish-path <root> результат записывается в <root>/applib и
<root>/appsrc. Флаг поддерживается только для SBT-проектов.
Для гарантированного заполнения нового каталога публикации команда с --build-appsrc выполняет чистую SBT-сборку.
Не указывайте один --publish-path при сборке нескольких проектов: запускайте команду отдельно с -p
и уникальным корневым каталогом для каждого проекта.
Если в project.yaml явно задано isPublishSrcFolder: false, SBT-плагин не публикует исходные артефакты;
по умолчанию этот параметр включен.
GSF CLI формирует каталоги с JAR-файлами, но не создает applib.zip и appsrc.zip. Упаковку и
загрузку этих архивов выполняйте на следующем шаге CI/CD или средствами nscli.
--publish-path задает только локальный корень. Без --skip-publication обычная команда build дополнительно
выполняет
sbt publish: при включенном isPublishSrcFolder он публикует отдельные *-sources.jar в настроенный
Maven-репозиторий,
но не публикует весь каталог appsrc или appsrc.zip как один артефакт.
Если версия release уже отмечена в кеше как собранная, build --build-appsrc восстановит недостающие локальные
каталоги без повторной удаленной публикации. Если первая сборка выполнялась с --skip-publication, а затем артефакты
нужно
отправить в Maven-репозиторий, запустите manage.sh -p <project_name> publish отдельно.
Относительный --publish-path считается от workspace/sources/<project_name>/application, а не от каталога, из
которого вызвана команда. Абсолютный путь задаёт место результата напрямую.
В applib также записывается metadata.yaml с источником GlobalServer, временем и хостом сборки. При --build-appsrc
CLI сохраняет служебный .gsf-publish-manifest.yaml в корне публикации для проверки полноты release-результата.
Для подробного вывода SBT-задачи используйте ярлык sbt.cmd или sbt.shиз workspace/links/<project_name>, например
sbt.cmd -debug "publishDevDependencies" в CMD. Полные примеры для
Linux и
Windows приведены в разделах диагностики.
Test#
Для SBT обновляет исходники, модули, окружение, сервер и плагин, затем выполняет update; compile; test.
Внимание
После успешных тестов текущая реализация вызывает publish. У команды test нет флага отключения публикации. Не используйте её как проверку окружения без побочных действий. Для release-версии, уже отмеченной в кеше как собранная, команда может завершиться без повторного запуска тестов.
usage: manage.sh test [-h]
Выполняет юнит тестирование
options:
-h, --help show this help message and exit
Clean#
Удаляет только workspace/cache/<project_name>/cache.json. Исходники, JAR-файлы и кеши SBT/Ivy/Coursier остаются на
месте. Вместе со служебным кешем теряется запись о ранее собранной release-версии.
usage: manage.sh clean [-h]
Очистить
options:
-h, --help show this help message and exit
Update_module_dependency#
usage: manage.sh update_module_dependency [-h] [--force]
Обновление зависимостей модулей.
Команда актуализирует версии модулей в `project.yaml` в соответствии с требованиями в `module-info.xml` для текущего модуля.
Проверка начинается с первого модуля в `project.yaml`.
При изменении версии какого либо модуля от которого зависит текущий модуль, происходит повторная проверка зависимостей измененного модуля.
При нахождении расхождений в модуле подключенному по исходному коду меняется `project.yaml`.
В случае если зависимость идет от комплекта сборки, выдается предупреждение.
options:
-h, --help show this help message and exit
--force Актуализирует 'project.yaml' не спрашивая пользователя
Save_external_dependencies#
Вызывает SBT-задачу сохранения реестра внешних библиотек. Если файл не задан, запрашивает путь. При существующем файле
спрашивает о перезаписи, в том числе при переданном --file. Для headless указывайте новый путь. Примеры для обеих ОС —
в главе о реестре библиотек.
usage: manage.sh save_external_dependencies [-h] [-f [FILE]]
options:
-h, --help show this help message and exit
-f [FILE], --file [FILE]
Файл, в который необходимо сохранить список
Diff_external_dependencies#
Сравнивает сохранённый файл с текущим реестром проекта. В headless передавайте существующий файл через --file, чтобы
не открывать диалог выбора пути.
usage: manage.sh diff_external_dependencies [-h] [-f [FILE]]
options:
-h, --help show this help message and exit
-f [FILE], --file [FILE]
Файл для сравнения, в котором хранится список внешних
зависимостей
Upload_base_source_kit#
usage: manage.sh upload_base_source_kit [-h]
Выгружает baseSourceKit:
Выгрузка конфигурации проекта в репозиторий, указанный в project.yaml `mirrorConfigSource`.
Выгрузка исходников модулей проекта в репозитории, указанные в project.yaml `module:mirrorSource`.
options:
-h, --help show this help message and exit
Load_base_source_kit#
usage: manage.sh load_base_source_kit [-h]
Загружает baseSourceKit:
Загрузка конфигурации проекта в application/build/sourceKit из project.yaml `baseSourceKit`.
Загрузка исходников модулей проекта через загруженную конфигурацию project.yaml `module:mirrorSource`.
options:
-h, --help show this help message and exit