Maven trebuie să ajungă la pluginul proxy înainte de a-l putea rula

Un plugin proxy automat sună ideal pentru un laptop care se mută între rețele. Există însă o primă cerere incomodă: Maven poate avea nevoie de proxy pentru a obține pluginul în sine.

O țintă de plugin rulează doar după ce Maven poate rezolva și încărca implementarea și artefactele necesare. Descoperirea proxy din interiorul acelei implementări nu poate ajuta o descărcare care eșuează înainte de pornirea implementării. Folosirea coordonatelor complet calificate ale pluginului poate evita o căutare după prefix; dar nu face artefactul pluginului să apară într-un depozit local gol.

Vechiul plugin Autoproxy pentru Maven ilustrează distincția. README-ul său descrie descoperirea proxy prin proxy-vole, dar descrie și instalarea locală a pluginului înainte de a-i invoca ținta. Tratați asta ca pe o condiție prealabilă a acelui design anume, nu ca dovadă că Maven citește universal setările PAC ale browserului.

Dați primei rezolvări o rută explicită

Pentru o rețea în care accesul la depozit necesită un proxy HTTP, configurați proxyul activ potrivit în setările Maven folosite de acea invocare. Pentru un bootstrap permis dintr-un depozit public, alegeți un candidat HTTP din lista de proxyuri HTTP. Un depozit intern aprobat, accesibil fără ruta externă, poate rezolva și problema accesului inițial. Orice abordare trebuie să acopere pluginul și dependențele sale, nu doar dependențele aplicației.

Un depozit local deja populat poate ascunde cerința de bootstrap. Succesul pe laptopul unui dezvoltator nu dovedește că un cont CI nou poate porni aceeași compilare. Uitați-vă la artefactul și faza care au eșuat înainte de a schimba logica de detectare a pluginului.

După ce pluginul este încărcat, o eșuare ulterioară a dependențelor devine o întrebare separată: dacă ruta detectată este corectă și dacă transportul Maven activ folosește setările rezultate. Țineți cele două puncte de eșec separate când decideți dacă detectarea automată merită păstrată.