Отримайте перше завантаження 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, недоступний репозиторій і відхилений вхід через проксі можуть з'явитися під час розв'язання залежностей, але вимагають дуже різних виправлень.