Hämta sbts första nedladdning via proxyn

sbt kan behöva nätverket innan din byggdefinition har gjort något användbart. Dess launcher måste hämta komponenter, och bygget kan senare kontakta förråd via ytterligare bibliotek. En proxyinställning som är gömd i en uppgift kan komma för sent för den första nedladdningen.

Börja med JVM:en som faktiskt kör sbt. För en launcher som läser projektets .jvmopts kan grundläggande slutpunktsegenskaper vara:

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

Dessa värden skiljer ett värdnamn och en port; de är inte fullständiga proxy-URL:er. För tillåtna nedladdningar från offentliga förråd tillhandahåller HTTP-proxylistan kandidatvärden för dessa fält. Ett HTTPS-förråd kan fortfarande nås via en HTTP-proxy med CONNECT.

Lägg märke till vilken nedladdning som misslyckades

Launcherns bootstrap, byggverktygets komponenter, plugins och beroenden använder inte nödvändigtvis samma konfigurationslager. Identifiera den misslyckade URL:en och fasen innan du redigerar förrådsdeklarationer.

Val av förråd svarar på var artefakter hämtas från. Proxykonfiguration svarar på hur en nätverksklient når den slutpunkten. Att ersätta ett förråd med en intern spegel kan vara ett separat stött val, men det konfigurerar inte en nätverksproxy för alla andra destinationer.

Proxyautentisering är ytterligare en kontroll. Anta inte att varje Java-nedladdare behandlar en godtycklig proxyUser-egenskap som en stödd inloggningsmekanism. Använd det autentiseringsupplägg som dokumenteras för den installerade launchern och den relevanta resolvern.

Kontrollera slutligen launchermiljön så som den faktiskt är, i stället för att kopiera en variabel från en guide för en annan runner. Ett DNS-fel, ett otillgängligt förråd och en avvisad proxyinloggning kan alla dyka upp under beroendeupplösningen, men kräver mycket olika åtgärder.