Maven må nå proxy-pluginen før det kan køyra han

Ein automatisk proxy-plugin høyrest ideell ut for ein berbar PC som flyttar seg mellom nettverk. Det finst éin vanskeleg første førespurnad: Maven kan trenga proxyen for å henta sjølve pluginen.

Eit plugin-mål køyrer først når Maven kan løysa opp og lasta inn implementasjonen og dei nødvendige artefakta. Proxy-oppdaging inne i den implementasjonen kan ikkje hjelpa ei nedlasting som feilar før implementasjonen startar. Bruk av fullt kvalifiserte plugin-koordinatar kan unngå eit prefiksoppslag; det får likevel ikkje plugin-artefakten til å dukka opp i eit tomt lokalt depot.

Den gamle Autoproxy Maven-pluginen illustrerer skiljet. README-fila skildrar proxy-oppdaging via proxy-vole, men skildrar òg lokal installasjon av pluginen før målet vert kalla. Handsame det som ein føresetnad for akkurat det designet, ikkje som prov for at Maven generelt les PAC-innstillingane til nettlesaren.

Gje den første oppløysinga ei eksplisitt rute

For eit nettverk der depotåtkomst krev ein HTTP-proxy, konfigurer den aktuelle aktive proxyen i Maven-innstillingane som den køyringa brukar. For ein tillaten bootstrap frå eit offentleg depot, vel ein HTTP-kandidat frå HTTP-proxy-lista. Eit godkjent internt depot som er tilgjengeleg utan den eksterne ruta, kan òg løysa det første åtkomstproblemet. Begge tilnærmingane må dekkja pluginen og avhengnadene hans, ikkje berre avhengnadene til applikasjonen.

Eit tidlegare fylt lokalt depot kan skjula bootstrap-kravet. Suksess på den berbare PC-en til ein utviklar provar ikkje at ein fersk CI-konto kan starta same bygg. Sjå på artefakten og fasen som feilar før du endrar deteksjonslogikken til pluginen.

Etter at pluginen er lasta, vert ein seinare avhengnadsfeil eit eige spørsmål: om den oppdaga ruta er rett, og om den aktive Maven-transporten brukar innstillingane som følgjer. Hald dei to feilpunkta skilde når du avgjer om automatisk oppdaging er verdt å behalda.