Автоматический прокси-плагин кажется идеальным для ноутбука, который перемещается между сетями. Но есть один неудобный первый запрос: Maven может понадобиться прокси, чтобы получить сам плагин.

Цель плагина выполняется только после того, как Maven сможет разрешить и загрузить его реализацию и необходимые артефакты. Обнаружение прокси внутри этой реализации не поможет загрузке, которая завершается ошибкой до запуска реализации. Использование полностью квалифицированных координат плагина может избежать поиска по префиксу; но оно не заставляет артефакт плагина появиться в пустом локальном репозитории.

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

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

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

Ранее заполненный локальный репозиторий может скрыть требование начальной загрузки. Успех на ноутбуке разработчика не доказывает, что свежая учётная запись CI сможет запустить ту же сборку. Посмотрите на сбойный артефакт и фазу, прежде чем менять логику обнаружения плагина.

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

Похожие статьи