Maven має дістатися до проксі-плагіна, перш ніж зможе його запустити

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

Ціль плагіна виконується лише після того, як Maven може розв'язати й завантажити його реалізацію та потрібні артефакти. Виявлення проксі всередині цієї реалізації не допоможе завантаженню, яке зривається до початку реалізації. Використання повністю кваліфікованих координат плагіна може уникнути пошуку за префіксом; але воно не змушує артефакт плагіна з'явитися в порожньому локальному репозиторії.

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

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

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

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

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