Получите первую загрузку sbt через прокси

sbt может потребовать сеть ещё до того, как ваше описание сборки сделает что-то полезное. Его лаунчер должен получить компоненты, а сборка позже может обращаться к репозиториям через дополнительные библиотеки. Настройка прокси, скрытая внутри задачи, может прийти слишком поздно для первой загрузки.

Начните с JVM, которая действительно запускает sbt. Для лаунчера, который читает .jvmopts проекта, базовые свойства конечной точки могут быть такими:

-Dhttp.proxyHost=proxy.example.net
-Dhttp.proxyPort=8080
-Dhttps.proxyHost=proxy.example.net
-Dhttps.proxyPort=8080

Эти значения разделяют имя хоста и порт; это не полные URL прокси. Для разрешённых загрузок из публичных репозиториев список HTTP-прокси предоставляет подходящие значения для этих полей. До репозитория HTTPS по-прежнему можно добраться через HTTP-прокси с помощью CONNECT.

Обратите внимание, какая загрузка не удалась

Начальная загрузка лаунчера, компоненты инструмента сборки, плагины и зависимости не обязательно используют один и тот же слой конфигурации. Определите неудавшийся URL и этап, прежде чем менять объявления репозиториев.

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

Аутентификация через прокси — ещё одна проверка. Не предполагайте, что каждая программа загрузки Java считает произвольное свойство proxyUser поддерживаемым механизмом входа. Используйте схему аутентификации, документированную для установленного лаунчера и соответствующего распознавателя.

Наконец, проверьте фактическое окружение лаунчера, а не копируйте переменную из руководства для другого runner. Сбой DNS, недоступный репозиторий и отклонённый вход через прокси могут проявиться во время разрешения зависимостей, но требуют совершенно разных исправлений.