Pata upakuaji wa kwanza wa sbt kupitia proksi

sbt inaweza kuhitaji mtandao kabla ya ufafanuzi wako wa ujenzi kufanya kitu chochote chenye manufaa. Kizindua chake lazima kipate vipengele, na ujenzi unaweza baadaye kuwasiliana na hifadhi kupitia maktaba za ziada. Mpangilio wa proksi uliofichwa ndani ya kazi unaweza kufika marehemu sana kwa upakuaji wa kwanza.

Anza na JVM inayoendesha sbt kwa kweli. Kwa kizindua kinachosoma .jvmopts ya mradi, sifa za msingi za mwisho zinaweza kuwa:

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

Thamani hizi hutenganisha jina la mwenyeji na bandari; si URL kamili za proksi. Kwa upakuaji unaoruhusiwa kutoka hifadhi za umma, orodha ya proksi za HTTP hutoa thamani mtarajiwa kwa sehemu hizo. Hifadhi ya HTTPS bado inaweza kufikiwa kupitia proksi ya HTTP kwa kutumia CONNECT.

Angalia ni upakuaji upi ulioshindwa

Uanzishaji wa kizindua, vipengele vya zana ya ujenzi, programu jalizi na vitegemezi si lazima vitumie tabaka sawa la usanidi. Tambua URL na hatua zilizoshindwa kabla ya kuhariri matangazo ya hifadhi.

Uchaguzi wa hifadhi hujibu bidhaa zinapopatikana. Usanidi wa proksi hujibu jinsi mteja wa mtandao anafikia mwisho huo. Kubadilisha hifadhi na kioo cha ndani kunaweza kuwa chaguo lingine linalotumika, lakini hakiweki proksi ya mtandao kwa maeneo mengine yote.

Uthibitishaji wa proksi ni ukaguzi mwingine. Usidhani kwamba kila kipakuzi cha Java kinachukulia sifa proxyUser yoyote kama utaratibu wa kuingia unaotumika. Tumia mpangilio wa uthibitishaji ulioandikwa kwa kizindua kilichosakinishwa na kitatuzi husika.

Mwishowe, angalia mazingira halisi ya kizindua badala ya kunakili kigezo kutoka mwongozo wa kikimbizaji kingine. Kushindwa kwa DNS, hifadhi isiyopatikana na kukataliwa kwa kuingia proksi vyote vinaweza kuonekana wakati wa kutatua vitegemezi, lakini vinahitaji marekebisho tofauti sana.