Менеджер проектов#

Для запуска используйте 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#

Для 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