SDKMAN — мёртв, да здравствует SDKMAN

TL;DR: SDKMAN CLI будет переписан на Golang

Шесть лет прошло с тех пор как мы выпустили первую версию SDKMAN. В более ранних версиях он был известен как GVM и использовался для управления Groovy и связанным с ним инструментарием. Вскоре стало очевидно, что он не должен ограничиваться экосистемой Groovy, и может также применяться к другим SDK на JVM. В этот момент GVM был переименован в SDKMAN. Хотя название и изменилось, основная технология осталась прежней.

Подобно тому, как GVM однажды перерос своё имя, SDKMAN перерос технологию, на которой он был построен. Несмотря на то, что сервисы бэкенда были заменены лучшими альтернативами, CLI клиент остался прежним и стал нашим самым большим источником разочарования.

В начале мы выбрали Bash для создания GVM, потому что он закрывал все требования. Он был доступен на всех *nix системах, быстро работал и предоставлял нам среду исполнения без каких-либо дополнительных зависимостей или накладных расходов. Это означало, что загрузка новой установки практически не требовала усилий почти на любой системе.

Несмотря на преимущества, которые нам дал Bash, со временем мы обнаружили множество проблем с этим выбором:

• пользователи Windows должны прыгать через обручи, устанавливая Cygwin / Git Bash
• наше программное обеспечение не всегда хорошо работает с альтернативными оболочками, такими как Fish shell
• необходимо поддерживать специальные хаки для совместимости с ZSH
• несовместимость между основными версиями Bash (и упорный отказ Apple от поставки OSX с современной версией Bash из-за глупых вопросов лицензирования)
• проблемы с сетью из-за использования curl в качестве основного http-клиента
• сложности с эффективным тестированием кода на Bash

Все это говорит нам, что пора бросить Bash в пользу чего-то еще, поэтому в последние месяцы я начал изучать Go как жизнеспособную альтернативу. После взвешивания шансов, плюсы реализации CLI на Go можно суммировать следующим образом:

• статически типизированный компилируемый язык, позволяющий обнаруживать ошибки во время разработки
• исполняется невероятно быстро
• больше нет зависимости от зыбкой почвы Bash под ногами
• создает изначально скомпилированные двоичные файлы для всех архитектур, устраняя неожиданные связанные с платформой побочные эффекты
• более легкая поддержка приемочного тестирования через Godog (версия Cucumber, написанная в Go)
• позволяет переосмыслить некоторое поведение текущей реализации SDKMAN (подробнее об этом позже)
• позволяет улучшить сотрудничество и увеличить вклад членов сообщества
• прост и позволяет нам просто сделать эту чертову работу (Get Shit Done)

Понимая всё это, я решил построить первую рабочую версию нового CLI-интерфейса SDKMAN. После завершения этой работы новая версия станет стандартной версией SDKMAN. Конечно, это также позволит нам пересмотреть то, как он функционирует в настоящее время. Через шесть лет мы узнали, что работает и не работает, и можем довести эти знания до ума в нашей блестящей новой версии.

Здесь мы призываем наше сообщество присоединиться и стать частью общения. Мы хотим знать, какие функции вы хотели бы видеть (или не хотели бы). Для этого мы открываем новую комнату в Gitter. Мы приглашаем вас присоединиться и принять участие, давая обратную связь на новый CLI. Мы все еще используем Cucumber для описания поведения в понятном для понимания языке так же, как и в случае с версией Bash, и просим всех принять участие в реализации каждой функции. Как и прежде, мы хотим, чтобы эти функции составляли живую документацию.

Именно поэтому я назвал этот пост так. Нам нравилось разрабатывать оригинальную версию SDKMAN, но мы поняли, что в ней есть проблемы. Теперь у нас есть возможность сделать его более надежным и улучшить его для всех. Мы будем рады любой помощи на пути к реализации нового CLI!

От переводчика: SDKMAN — один из самых любимых мною пакетных менеджеров, с него начинается установка JVM, Gradle и Kotlin на новой машине. Именно поэтому, совсем недавно мы в CUBA Platform начали публиковать в SDKMAN свою утилиту CUBA CLI. Я сделал этот перевод, поскольку рад видеть развитие SDKMAN и с нетерпением жду его новой версии.