Вземете първото изтегляне на 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 като поддържан механизъм за вход. Използвайте удостоверяването, документирано за инсталирания стартер и съответния resolver.

Накрая проверете действителната среда на стартера, вместо да копирате променлива от ръководство за друг runner. DNS отказ, недостъпно хранилище и отказан прокси вход могат да се появят по време на разрешаването на зависимости, но изискват много различни поправки.