Maven mora doći do proxy dodatka prije nego što ga može pokrenuti

Automatski proxy dodatak zvuči idealno za prijenosno računalo koje se kreće između mreža. Postoji jedan nezgodan prvi zahtjev: Maven može trebati proxy da bi dobio sam dodatak.

Cilj dodatka se izvršava tek nakon što Maven može razriješiti i učitati njegovu implementaciju i potrebne artefakte. Otkrivanje proxyja unutar te implementacije ne može pomoći preuzimanju koje ne uspije prije nego što implementacija počne. Korištenje potpuno kvalifikovanih koordinata dodatka može izbjeći pretragu po prefiksu; ali ne čini da se artefakt dodatka pojavi u praznom lokalnom repozitoriju.

Stari Autoproxy Maven dodatak ilustruje razliku. Njegov README opisuje otkrivanje proxyja putem proxy-vole, ali opisuje i lokalnu instalaciju dodatka prije pozivanja njegovog cilja. Tretirajte to kao preduvjet tog konkretnog dizajna, a ne kao dokaz da Maven univerzalno čita PAC postavke preglednika.

Dajte prvom razrješenju eksplicitnu rutu

Za mrežu u kojoj pristup repozitoriju zahtijeva HTTP proxy, konfigurirajte odgovarajući aktivni proxy u Maven postavkama koje koristi taj poziv. Za dopušteno početno preuzimanje iz javnog repozitorija odaberite HTTP kandidata sa liste HTTP proxyja. Odobreni interni repozitorij dostupan bez vanjske rute također može riješiti problem početnog pristupa. Svaki pristup mora pokriti dodatak i njegove zavisnosti, ne samo zavisnosti aplikacije.

Prethodno popunjen lokalni repozitorij može prikriti zahtjev za početnim preuzimanjem. Uspjeh na prijenosnom računalu razvijača ne dokazuje da novi CI račun može pokrenuti istu gradnju. Pogledajte artefakt i fazu koji nisu uspjeli prije nego što promijenite logiku otkrivanja dodatka.

Nakon što se dodatak učita, kasniji neuspjeh zavisnosti postaje zasebno pitanje: je li otkrivena ruta ispravna i koristi li aktivni Maven transport rezultirajuće postavke. Držite te dvije točke neuspjeha odvojenima kada odlučujete vrijedi li zadržati automatsko otkrivanje.