Maven мора да стигне до прокси додатка пре него што може да га покрене

Аутоматски прокси додатак звучи идеално за преносни рачунар који се креће између мрежа. Постоји један незгодан први захтев: Maven може да затражи прокси да би добио сам додатак.

Циљ додатка се извршава тек након што Maven може да разреши и учита његову имплементацију и потребне артефакте. Откривање проксија унутар те имплементације не може да помогне преузимању које не успе пре него што имплементација почне. Коришћење потпуно квалификованих координата додатка може да избегне претрагу по префиксу; али не чини да се артефакт додатка појави у празном локалном репозиторијуму.

Стари Autoproxy Maven додатак илуструје разлику. Његов README описује откривање проксија преко proxy-vole, али описује и локалну инсталацију додатка пре позивања његовог циља. Третирајте то као предуслов тог конкретног дизајна, а не као доказ да Maven универзално чита PAC поставке прегледача.

Дајте првом решавању експлицитну путању

За мрежу у којој приступ репозиторијуму захтева HTTP прокси, конфигуришите одговарајући активни прокси у Maven поставкама које користи тај позив. За дозвољено почетно преузимање из јавног репозиторијума изаберите HTTP кандидата са списка HTTP проксија. Одобрени интерни репозиторијум доступан без спољне путање такође може да реши проблем почетног приступа. Сваки приступ мора да покрије додатак и његове зависности, не само зависности апликације.

Претходно попуњен локални репозиторијум може да прикрије захтев за почетним преузимањем. Успех на преносном рачунару програмера не доказује да нови CI налог може да покрене исту градњу. Погледајте артефакт и фазу који нису успели пре него што промените логику откривања додатка.

Након што се додатак учита, каснији неуспех зависности постаје засебно питање: да ли је откривена путања исправна и да ли активни Maven транспорт користи резултујуће поставке. Држите те две тачке неуспеха одвојеним када одлучујете да ли аутоматско откривање вреди задржати.