Akiru la unuan elŝuton de sbt tra la prokura servilo

Agordu la JVM-on, kiu rulas sbt, kaj distingigu lanĉilajn elŝutojn, elekton de deponejo kaj prokuran aŭtentikigon.

sbt povas bezoni la reton antaŭ ol via konstrua difino faris ion utilan. Ĝia lanĉilo devas akiri komponentojn, kaj la konstruo povas poste kontakti deponejojn per pliaj bibliotekoj. Prokura agordo kaŝita en tasko povas alveni tro malfrue por la unua elŝuto.

Komencu per la JVM, kiu efektive rulas sbt. Por lanĉilo, kiu legas la .jvmopts de la projekto, bazaj finpunktaj atributoj povas esti:

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

Ĉi tiuj valoroj apartigas gastigantnomon kaj pordon; ili ne estas plenaj prokuraj URL-oj. Por permesitaj elŝutoj el publikaj deponejoj, la listo de HTTP-prokuroj provizas kandidatajn valorojn por tiuj kampoj. HTTPS-deponejo ankoraŭ estas atingebla tra HTTP-prokuro per CONNECT.

Rimarku, kiu elŝuto malsukcesis

Lanĉila startigo, komponentoj de la konstruilo, kromprogramoj kaj dependecoj ne nepre uzas la saman agordan tavolon. Identigu la malsukcesan URL-on kaj la etapon antaŭ ol redakti deponejajn deklarojn.

Deponeja elekto respondas, de kie oni akiras artefaktojn. Prokura agordo respondas, kiel reta kliento atingas tiun finpunkton. Anstataŭigi deponejon per interna spegulo povas esti aparta subtenata elekto, sed ĝi ne agordas retan prokuron por ĉiuj aliaj celoj.

Prokura aŭtentikigo estas plia kontrolo. Ne supozu, ke ĉiu Java-elŝutilo traktas arbitran atributon proxyUser kiel subtenatan ensalutan mekanismon. Uzu la aŭtentikigan aranĝon dokumentitan por la instalita lanĉilo kaj la koncerna solvilo.

Fine, kontrolu la efektivan lanĉilan medion anstataŭ kopii variablon el gvidilo por alia rulilo. DNS-malsukceso, neatingebla deponejo kaj rifuzita prokura ensaluto povas ĉiuj aperi dum dependeca solvado, sed ili postulas tre malsamajn korektojn.

Rilataj artikoloj