sbt może potrzebować sieci, zanim twoja definicja kompilacji zrobi coś pożytecznego. Jego launcher musi pobrać komponenty, a kompilacja może później kontaktować się z repozytoriami przez dodatkowe biblioteki. Ustawienie proxy ukryte w zadaniu może przyjść zbyt późno na pierwsze pobranie.

Zacznij od JVM, która faktycznie uruchamia sbt. Dla launchera czytającego .jvmopts projektu podstawowe właściwości punktu końcowego mogą być następujące:

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

Te wartości rozdzielają nazwę hosta i port; nie są to pełne adresy URL proxy. Dla dozwolonych pobrań z publicznych repozytoriów lista proxy HTTP dostarcza kandydackie wartości tych pól. Repozytorium HTTPS nadal można osiągnąć przez proxy HTTP za pomocą CONNECT.

Zauważ, które pobranie się nie powiodło

Bootstrap launchera, komponenty narzędzia kompilacji, wtyczki i zależności niekoniecznie korzystają z tej samej warstwy konfiguracji. Zanim zmienisz deklaracje repozytoriów, ustal, który adres URL i etap zawiodły.

Wybór repozytorium odpowiada na pytanie, skąd pochodzą artefakty. Konfiguracja proxy odpowiada na pytanie, jak klient sieciowy dociera do tego punktu końcowego. Zastąpienie repozytorium wewnętrznym serwerem lustrzanym może być osobną obsługiwaną opcją, ale nie konfiguruje proxy sieciowego dla wszystkich pozostałych miejsc docelowych.

Uwierzytelnianie proxy to kolejne sprawdzenie. Nie zakładaj, że każdy pobierający w Javie traktuje dowolną właściwość proxyUser jako obsługiwany mechanizm logowania. Użyj rozwiązania uwierzytelniania udokumentowanego dla zainstalowanego launchera i odpowiedniego resolwera.

Na koniec sprawdź faktyczne środowisko launchera, zamiast kopiować zmienną z poradnika dla innego runnera. Awaria DNS, niedostępne repozytorium i odrzucone logowanie proxy mogą wszystkie pojawić się podczas rozwiązywania zależności, ale wymagają bardzo różnych poprawek.

Powiązane artykuły