Samodejni vtičnik proxy se zdi idealen za prenosnik, ki se premika med omrežji. Vendar obstaja ena nerodna prva zahteva: Maven morda potrebuje proxy, da pridobi sam vtičnik.

Cilj vtičnika se izvede šele, ko Maven lahko razreši in naloži njegovo izvedbo in zahtevane artefakte. Odkrivanje proxyja znotraj te izvedbe ne more pomagati prenosu, ki ne uspe, preden se izvedba začne. Uporaba popolnoma kvalificiranih koordinat vtičnika se lahko izogne iskanju po predponi; ne povzroči pa, da bi se artefakt vtičnika pojavil v praznem lokalnem skladišču.

Stari vtičnik Autoproxy za Maven ponazarja razliko. Njegov README opisuje odkrivanje proxyja prek proxy-vole, opisuje pa tudi lokalno namestitev vtičnika pred klicem njegovega cilja. To obravnavajte kot predpogoj te posebne zasnove, ne kot dokaz, da Maven splošno bere nastavitve PAC brskalnika.

Prvi rešitvi dajte jasno pot

Za omrežje, kjer dostop do skladišča zahteva proxy HTTP, nastavite ustrezen aktivni proxy v nastavitvah Mavena, ki jih uporablja ta klic. Za dovoljen zagon iz javnega skladišča izberite kandidata HTTP s seznama proxyjev HTTP. Odobreno notranje skladišče, dostopno brez zunanje poti, lahko prav tako reši težavo začetnega dostopa. Vsak pristop mora zajeti vtičnik in njegove odvisnosti, ne le odvisnosti aplikacije.

Prej napolnjeno lokalno skladišče lahko skrije zahtevo po zagonu. Uspeh na razvijalčevem prenosniku ne dokazuje, da lahko nov račun CI začne isto gradnjo. Preden spremenite logiko zaznavanja vtičnika, poglejte artefakt in fazo, ki nista uspela.

Po nalaganju vtičnika poznejša napaka odvisnosti postane ločeno vprašanje: ali je zaznana pot pravilna in ali aktivni transport Mavena uporablja nastale nastavitve. Ti dve točki napake držite ločeno, ko se odločate, ali je samodejno zaznavanje vredno obdržati.

Sorodni članki