Maven turi pasiekti proxy papildinį, kol gali jį paleisti

Automatinis proxy papildinys skamba idealiai nešiojamajam kompiuteriui, judančiam tarp tinklų. Tačiau yra vienas nepatogus pirmasis prašymas: Maven gali prireikti proxy, kad gautų patį papildinį.

Papildinio tikslas vykdomas tik tada, kai Maven gali išspręsti ir įkelti jo įgyvendinimą bei reikiamus artefaktus. Proxy aptikimas tame įgyvendinime negali padėti atsisiuntimui, kuris nepavyksta prieš prasidedant įgyvendinimui. Visiškai kvalifikuotų papildinio koordinačių naudojimas gali išvengti priešdėlio paieškos; bet jis nepriverčia papildinio artefakto atsirasti tuščiame vietiniame saugykloje.

Senas Autoproxy Maven papildinys iliustruoja šį skirtumą. Jo README aprašo proxy aptikimą per proxy-vole, bet taip pat aprašo vietinį papildinio įdiegimą prieš iškviečiant jo tikslą. Laikykite tai to konkretaus dizaino prielaida, o ne įrodymu, kad Maven visuotinai skaito naršyklės PAC nustatymus.

Suteikite pirmajam sprendimui aiškų maršrutą

Tinklui, kuriame prieiga prie saugyklos reikalauja HTTP proxy, sukonfigūruokite tinkamą aktyvų proxy Maven nuostatose, kurias naudoja tas iškvietimas. Leidžiamam viešosios saugyklos paleidimui pasirinkite HTTP kandidatą iš HTTP proxy sąrašo. Patvirtinta vidinė saugykla, pasiekiama be išorinio maršruto, taip pat gali išspręsti pradinės prieigos problemą. Bet kuris metodas turi apimti papildinį ir jo priklausomybes, o ne tik programos priklausomybes.

Anksčiau užpildyta vietinė saugykla gali paslėpti paleidimo reikalavimą. Sėkmė kūrėjo nešiojamajame kompiuteryje neįrodo, kad nauja CI paskyra gali pradėti tą patį kūrimą. Pažiūrėkite į nepavykusį artefaktą ir fazę prieš keisdami papildinio aptikimo logiką.

Įkėlus papildinį, vėlesnė priklausomybės klaida tampa atskiru klausimu: ar aptiktas maršrutas yra teisingas ir ar aktyvus Maven transportas naudoja gautas nuostatas. Laikykite šiuos du gedimo taškus atskirai, kai sprendžiate, ar verta išlaikyti automatinį aptikimą.