Maven må nå proxy-pluginen før det kan kjøre den
Forstå oppstartsproblemet når en Maven-plugin lover å oppdage en proxy, men dens egne artefakter ikke kan løses.
En automatisk proxy-plugin høres ideell ut for en bærbar PC som flytter seg mellom nettverk. Det er én vanskelig første forespørsel: Maven kan trenge proxyen for å hente selve pluginen.
Et plugin-mål kjøres først når Maven kan løse og laste inn implementasjonen og de nødvendige artefaktene. Proxy-oppdagelse inne i den implementasjonen kan ikke hjelpe en nedlasting som feiler før implementasjonen starter. Fullt kvalifiserte plugin-koordinater kan unngå et prefiksoppslag; men de får ikke plugin-artefakten til å dukke opp i et tomt lokalt depot.
Den gamle Autoproxy Maven-pluginen illustrerer skillet. README-filen beskriver proxy-oppdagelse via proxy-vole, men beskriver også lokal installasjon av pluginen før målet kalles. Behandle det som en forutsetning for akkurat det designet, ikke som bevis for at Maven generelt leser nettleserens PAC-innstillinger.
Gi den første løsningen en eksplisitt rute
For et nettverk der depotilgang krever en HTTP-proxy, konfigurer den aktuelle aktive proxyen i Maven-innstillingene som den kjøringen bruker. For en tillatt bootstrap fra et offentlig depot, velg en HTTP-kandidat fra HTTP-proxy-listen. Et godkjent internt depot som er tilgjengelig uten den eksterne ruten, kan også løse det første tilgangsproblemet. Begge tilnærmingene må dekke pluginen og dens avhengigheter, ikke bare applikasjonens avhengigheter.
Et tidligere fylt lokalt depot kan skjule bootstrap-kravet. Suksess på en utviklers bærbare PC beviser ikke at en fersk CI-konto kan starte samme bygg. Se på artefakten og fasen som feiler før du endrer pluginens deteksjonslogikk.
Etter at pluginen er lastet, blir en senere avhengighetsfeil et eget spørsmål: om den oppdagede ruten er riktig, og om den aktive Maven-transporten bruker innstillingene som følger. Hold de to feilpunktene adskilt når du avgjør om automatisk oppdagelse er verdt å beholde.