Атрымайце першае запампоўванне 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 падтрыманым механізмам уваходу. Выкарыстоўвайце схему аўтэнтыфікацыі, дакументаваную для ўсталяванага запускальніка і адпаведнага распазнавальніка.

Нарэшце, праверце фактычнае асяроддзе запускальніка, а не капіруйце зменную з кіраўніцтва для іншага выканаўцы. Збой DNS, недаступны рэпазіторый і адхілены ўваход праз проксі могуць з'явіцца падчас вырашэння залежнасцей, патрабуючы вельмі розных выпраўленняў.