Få den første nedlastingen av sbt gjennom proxyen

sbt kan trenge nettverket før byggdefinisjonen din har gjort noe nyttig. Launcheren må hente komponenter, og bygget kan senere kontakte repositorier gjennom flere biblioteker. En proxy-innstilling som er skjult i en oppgave, kan komme for sent til den første nedlastingen.

Start med JVM-en som faktisk kjører sbt. For en launcher som leser prosjektets .jvmopts, kan grunnleggende endepunktsegenskaper være:

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

Disse verdiene skiller et vertsnavn og en port; de er ikke fullstendige proxy-URL-er. For tillatte nedlastinger fra offentlige repositorier gir HTTP-proxy-listen kandidatverdier for disse feltene. Et HTTPS-repositorium kan fortsatt nås gjennom en HTTP-proxy ved hjelp av CONNECT.

Legg merke til hvilken nedlasting som mislyktes

Launcherens oppstart, byggeverktøyets komponenter, plugins og avhengigheter bruker ikke nødvendigvis samme konfigurasjonslag. Identifiser URL-en og trinnet som mislyktes før du redigerer repositoriedeklarasjoner.

Valg av repositorium svarer på hvor artefakter hentes fra. Proxy-konfigurasjon svarer på hvordan en nettverksklient når det endepunktet. Å erstatte et repositorium med et internt speil kan være et eget støttet valg, men det konfigurerer ikke en nettverksproxy for alle andre destinasjoner.

Proxy-autentisering er nok en sjekk. Ikke anta at enhver Java-nedlaster behandler en vilkårlig proxyUser-egenskap som en støttet innloggingsmekanisme. Bruk autentiseringsoppsettet som er dokumentert for den installerte launcheren og den aktuelle resolveren.

Til slutt, sjekk launchermiljøet slik det faktisk er, i stedet for å kopiere en variabel fra en veiledning for en annen runner. En DNS-feil, et utilgjengelig repositorium og en avvist proxy-innlogging kan alle dukke opp under avhengighetsoppløsningen, men krever svært forskjellige rettelser.