Maven павінен дасягнуць проксі-плагіна, перш чым зможа яго запусціць

Аўтаматычны проксі-плагін здаецца ідэальным для ноўтбука, які перамяшчаецца паміж сеткамі. Але ёсць адзін няёмкі першы запыт: Maven можа спатрэбіцца проксі, каб атрымаць сам плагін.

Мэта плагіна выконваецца толькі пасля таго, як Maven зможа развязаць і загрузіць яго рэалізацыю і патрэбныя артэфакты. Пошук проксі ўнутры гэтай рэалізацыі не дапаможа загрузцы, якая зрываецца да пачатку рэалізацыі. Выкарыстанне цалкам кваліфікаваных каардынат плагіна можа пазбегнуць пошуку па прэфіксе; але яно не прымушае артэфакт плагіна з'явіцца ў пустым лакальным рэпазіторыі.

Стары плагін Autoproxy для Maven ілюструе гэтую розніцу. Яго README апісвае пошук проксі праз proxy-vole, але таксама апісвае лакальную ўстаноўку плагіна перад выклікам яго мэты. Разглядайце гэта як папярэднюю ўмову таго канкрэтнага дызайну, а не як доказ таго, што Maven універсальна чытае налады PAC браўзера.

Дайце першаму развязанню яўны маршрут

Для сеткі, дзе доступ да рэпазіторыя патрабуе HTTP-проксі, наладзьце адпаведны актыўны проксі ў наладах Maven, якія выкарыстоўвае гэты выклік. Для дазволенай першапачатковай загрузкі з публічнага рэпазіторыя выберыце HTTP-кандыдата са спісу HTTP-проксі. Зацверджаны ўнутраны рэпазіторый, дасяжны без знешняга маршруту, таксама можа вырашыць праблему першапачатковага доступу. Любы падыход павінен пакрываць плагін і яго залежнасці, а не толькі залежнасці праграмы.

Раней запоўнены лакальны рэпазіторый можа схаваць патрабаванне першапачатковай загрузкі. Поспех на ноўтбуку распрацоўшчыка не даказвае, што новы ўліковы запіс CI можа пачаць тую ж зборку. Паглядзіце на артэфакт і фазу, якія збаілі, перш чым змяняць логіку выяўлення плагіна.

Пасля загрузкі плагіна наступны збой залежнасці становіцца асобным пытаннем: ці правільны выяўлены маршрут і ці выкарыстоўвае актыўны транспарт Maven атрыманыя налады. Трымайце гэтыя два пункты збою асобна, калі вырашаеце, ці варта захоўваць аўтаматычнае выяўленне.