Maven ir jāsasniedz proxy spraudnis, pirms tas var to palaist

Automātisks starpniekservera spraudnis šķiet ideāls klēpjdatoram, kas pārvietojas starp tīkliem. Tomēr ir viens neērts pirmais pieprasījums: Maven var būt nepieciešams starpniekserveris, lai iegūtu pašu spraudni.

Spraudņa mērķis tiek izpildīts tikai pēc tam, kad Maven var atrisināt un ielādēt tā ieviešanu un nepieciešamos artefaktus. Starpniekservera atklāšana šajā ieviešanā nevar palīdzēt lejupielādei, kas neizdodas pirms ieviešanas sākuma. Pilnīgi kvalificētu spraudņa koordinātu izmantošana var izvairīties no prefiksa meklēšanas; taču tā nepadara spraudņa artefaktu redzamu tukšā vietējā krātuvē.

Vecais Autoproxy Maven spraudnis ilustrē šo atšķirību. Tā README apraksta starpniekservera atklāšanu ar proxy-vole, bet arī apraksta spraudņa lokālu instalēšanu pirms tā mērķa izsaukšanas. Uzskatiet to par šī konkrētā dizaina priekšnosacījumu, nevis pierādījumu, ka Maven vispārīgi lasa pārlūkprogrammas PAC iestatījumus.

Piešķiriet pirmajam risinājumam skaidru maršrutu

Tīklam, kurā piekļuve krātuvei prasa HTTP starpniekserveri, konfigurējiet atbilstošo aktīvo starpniekserveri Maven iestatījumos, ko izmanto šis izsaukums. Atļautai publiskas krātuves sāknēšanai izvēlieties HTTP kandidātu no HTTP starpniekserveru saraksta. Apstiprināta iekšējā krātuve, kas sasniedzama bez ārējā maršruta, arī var atrisināt sākotnējās piekļuves problēmu. Jebkurai pieejai jāaptver spraudnis un tā atkarības, nevis tikai lietojumprogrammas atkarības.

Iepriekš aizpildīta vietējā krātuve var paslēpt sāknēšanas prasību. Panākumi izstrādātāja klēpjdatorā nepierāda, ka jauns CI konts var sākt to pašu būvējumu. Apskatiet neizdevušos artefaktu un fāzi pirms spraudņa noteikšanas loģikas maiņas.

Pēc spraudņa ielādes vēlāka atkarības kļūda kļūst par atsevišķu jautājumu: vai atklātais maršruts ir pareizs un vai aktīvais Maven transports izmanto iegūtos iestatījumus. Turiet šos divus kļūmes punktus atsevišķi, lemjot, vai automātisko noteikšanu ir vērts saglabāt.