Haal de eerste download van sbt via de proxy

sbt kan het netwerk nodig hebben voordat je builddefinitie iets nuttigs heeft gedaan. De launcher moet componenten ophalen, en de build kan later repositories bereiken via extra bibliotheken. Een proxy-instelling die in een taak verborgen zit, kan te laat komen voor de eerste download.

Begin bij de JVM die sbt daadwerkelijk uitvoert. Voor een launcher die de .jvmopts van het project leest, kunnen de basiseigenschappen van het eindpunt zijn:

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

Deze waarden scheiden een hostnaam en een poort; het zijn geen volledige proxy-URL's. Voor toegestane downloads van openbare repositories levert de HTTP-proxylijst kandidaatwaarden voor die velden. Een HTTPS-repository is nog steeds bereikbaar via een HTTP-proxy met CONNECT.

Let op welke download is mislukt

Launcher-bootstrap, componenten van de buildtool, plug-ins en afhankelijkheden gebruiken niet noodzakelijk dezelfde configuratielaag. Identificeer de mislukte URL en fase voordat je repositorydeclaraties aanpast.

Repositorykeuze beantwoordt waar artefacten vandaan komen. Proxyconfiguratie beantwoordt hoe een netwerkclient dat eindpunt bereikt. Een repository vervangen door een interne mirror kan een aparte ondersteunde keuze zijn, maar het configureert geen netwerkproxy voor alle andere bestemmingen.

Proxy-authenticatie is nog een controle. Ga er niet van uit dat elke Java-downloader een willekeurige proxyUser-eigenschap als een ondersteund inlogmechanisme behandelt. Gebruik de authenticatieregeling die is gedocumenteerd voor de geïnstalleerde launcher en de relevante resolver.

Controleer ten slotte de daadwerkelijke launcheromgeving in plaats van een variabele uit een gids voor een andere runner te kopiëren. Een DNS-fout, een niet-beschikbare repository en een geweigerde proxy-login kunnen allemaal tijdens het oplossen van afhankelijkheden optreden, maar vereisen heel verschillende oplossingen.