Maven musí dosáhnout na proxy plugin, než jej může spustit

Automatický proxy plugin zní ideálně pro notebook, který se pohybuje mezi sítěmi. Je tu však jeden nepříjemný první požadavek: Maven může potřebovat proxy k získání samotného pluginu.

Cíl pluginu se spustí až poté, co Maven dokáže vyřešit a načíst jeho implementaci a požadované artefakty. Objevování proxy uvnitř této implementace nemůže pomoci stahování, které selže dříve, než se implementace spustí. Použití plně kvalifikovaných souřadnic pluginu může vyhnout se hledání podle předpony; nezpůsobí však, že se artefakt pluginu objeví v prázdném lokálním repozitáři.

Starý plugin Autoproxy pro Maven tento rozdíl ilustruje. Jeho README popisuje objevování proxy přes proxy-vole, ale také popisuje lokální instalaci pluginu před voláním jeho cíle. Berte to jako předpoklad tohoto konkrétního návrhu, nikoli jako důkaz, že Maven obecně čte nastavení PAC prohlížeče.

Dejte prvnímu řešení jasnou cestu

Pro síť, kde přístup k repozitáři vyžaduje HTTP proxy, nakonfigurujte příslušnou aktivní proxy v nastavení Mavenu, které toto volání používá. Pro povolené první stažení z veřejného repozitáře vyberte HTTP kandidáta ze seznamu HTTP proxy. Schválený interní repozitář dostupný bez vnější cesty může také vyřešit problém počátečního přístupu. Oba přístupy musí pokrýt plugin a jeho závislosti, nejen závislosti aplikace.

Dříve naplněný lokální repozitář může skrýt požadavek prvního stažení. Úspěch na notebooku vývojáře neprokazuje, že nový účet CI může spustit stejné sestavení. Podívejte se na selhávající artefakt a fázi, než změníte logiku detekce pluginu.

Po načtení pluginu se pozdější selhání závislosti stává samostatnou otázkou: zda je zjištěná cesta správná a zda aktivní transport Mavenu používá výsledná nastavení. Při rozhodování, zda si automatickou detekci ponechat, držte tyto dva body selhání oddělené.