Automatyczna wtyczka proxy brzmi idealnie dla laptopa przenoszonego między sieciami. Jest jednak jedno niezręczne pierwsze żądanie: Maven może potrzebować proxy, aby pobrać samą wtyczkę.

Cel wtyczki uruchamia się dopiero po tym, jak Maven rozwiąże i wczyta jej implementację oraz wymagane artefakty. Wykrywanie proxy wewnątrz tej implementacji nie pomoże pobieraniu, które kończy się niepowodzeniem, zanim implementacja się zacznie. Użycie w pełni kwalifikowanych współrzędnych wtyczki może uniknąć wyszukiwania po prefiksie; nie sprawia jednak, że artefakt wtyczki pojawi się w pustym lokalnym repozytorium.

Stara wtyczka Autoproxy dla Mavena ilustruje tę różnicę. Jej README opisuje wykrywanie proxy przez proxy-vole, ale opisuje też lokalną instalację wtyczki przed wywołaniem jej celu. Traktuj to jako warunek wstępny tego konkretnego projektu, a nie dowód, że Maven powszechnie czyta ustawienia PAC przeglądarki.

Nadaj pierwszemu rozwiązaniu jawną trasę

Dla sieci, w której dostęp do repozytorium wymaga proxy HTTP, skonfiguruj odpowiednie aktywne proxy w ustawieniach Mavena używanych przez to wywołanie. Dla dozwolonego początkowego pobrania z publicznego repozytorium wybierz kandydata HTTP z listy proxy HTTP. Zatwierdzone wewnętrzne repozytorium osiągalne bez trasy zewnętrznej również może rozwiązać początkowy problem dostępu. Każde podejście musi obejmować wtyczkę i jej zależności, a nie tylko zależności aplikacji.

Wcześniej wypełnione lokalne repozytorium może ukryć wymóg początkowego pobrania. Sukces na laptopie dewelopera nie dowodzi, że nowe konto CI może rozpocząć tę samą kompilację. Spójrz na artefakt i fazę, które zawiodły, zanim zmienisz logikę wykrywania wtyczki.

Po wczytaniu wtyczki późniejszy błąd zależności staje się osobnym pytaniem: czy wykryta trasa jest poprawna i czy aktywny transport Mavena używa wynikowych ustawień. Utrzymuj te dwa punkty awarii osobno, decydując, czy automatyczne wykrywanie warto zachować.

Powiązane artykuły