Maven måste nå proxy-insticksmodulen innan det kan köra den

En automatisk proxy-insticksmodul låter idealisk för en bärbar dator som flyttar sig mellan nätverk. Det finns en besvärlig första begäran: Maven kan behöva proxyn för att hämta själva insticksmodulen.

Ett insticksmål körs först när Maven kan lösa upp och läsa in dess implementering och de artefakter som krävs. Proxy-upptäckt inuti den implementeringen kan inte hjälpa en nedladdning som misslyckas innan implementeringen startar. Att använda fullt kvalificerade instickskoordinater kan undvika en prefixsökning; det får dock inte insticksartefakten att dyka upp i ett tomt lokalt arkiv.

Den gamla Autoproxy-insticksmodulen för Maven illustrerar skillnaden. Dess README beskriver proxy-upptäckt via proxy-vole, men beskriver också lokal installation av insticksmodulen innan dess mål anropas. Behandla det som en förutsättning för just den designen, inte som bevis för att Maven generellt läser webbläsarens PAC-inställningar.

Ge den första upplösningen en explicit väg

För ett nätverk där åtkomst till arkivet kräver en HTTP-proxy, konfigurera lämplig aktiv proxy i de Maven-inställningar som det anropet använder. För en tillåten start från ett offentligt arkiv, välj en HTTP-kandidat från listan över HTTP-proxyer. Ett godkänt internt arkiv som nås utan den externa vägen kan också lösa det initiala åtkomstproblemet. Båda angreppssätten måste täcka insticksmodulen och dess beroenden, inte bara programmets beroenden.

Ett tidigare fyllt lokalt arkiv kan dölja startkravet. Framgång på en utvecklares bärbara dator bevisar inte att ett nytt CI-konto kan starta samma bygge. Titta på den misslyckade artefakten och fasen innan du ändrar insticksmodulens detektionslogik.

När insticksmodulen har lästs in blir ett senare beroendefel en separat fråga: om den upptäckta vägen är korrekt och om den aktiva Maven-transporten använder de inställningar som följer. Håll de två felpunkterna åtskilda när du avgör om automatisk upptäckt är värd att behålla.