Twój projekt nie zmienił się w pociągu do domu, ale jego trasa sieciowa tak. Adres serwera proxy, który działa w biurze, może być nieosiągalny w domu. To ustawienie środowiska, a nie powód, by wpisywać serwer proxy pracodawcy do POM projektu.

Model ustawień Mavena umieszcza definicje serwera proxy w najwyższej sekcji proxies. Profile ustawień nie dostarczają drugiej dowolnej kopii tej sekcji. Dodanie fragmentu XML w kształcie serwera proxy w obrębie profilu nie czyni go obsługiwanym mechanizmem przełączania sieci.

Prostą opcją jest utrzymywanie zatwierdzonych ustawień dla każdego środowiska i wybieranie odpowiedniego:

mvn --settings /path/to/settings-office.xml verify

Przykład jednoznacznie wybiera ustawienia użytkownika. Użyj polecenia i pliku odpowiednich dla kompilacji; nie oznacza to, że plik należy zatwierdzić wraz z poświadczeniami.

Utrzymuj różnice małe

Zapisz, które ustawienia faktycznie się różnią: aktywny serwer proxy, hosty pomijane, mirrory i wymagane konta serwerowe. Drugi plik nie powinien po cichu usuwać niepowiązanej polityki repozytorium ani używać starego hasła.

Sprawdź wszelkie ustawienia globalne, które nadal są scalane z wybranymi ustawieniami użytkownika. Jawny plik czyni dane wejściowe widocznymi, ale nie oznacza, że Maven nie ma innych źródeł konfiguracji.

Automatyczne przełączanie wymaga rzeczywistego sygnału

Maven nie potrafi w zwykłym sensie wywnioskować „biura” z położenia laptopa. Automatyczne rozwiązanie wymaga obsługiwanego zewnętrznego mechanizmu wykrywania lub zarządzania oraz określonej reakcji, gdy ten mechanizm jest niedostępny.

Uważaj na szerokie wzorce pomijania przeznaczone do wyłączania serwera proxy w domu. Mogą one również wpływać na cele wewnętrzne lub ukrywać, którą trasą poszło żądanie.

Przy pierwszej naprawie preferuj widoczny, jawny wybór ustawień. Gdy zadziała w obu środowiskach, dowolna automatyzacja może odtworzyć tę znaną konfigurację, zamiast wielokrotnie przepisywać instrukcje kompilacji projektu.

Powiązane artykuły