Jak mogę sprawić, by Maven przestał próbować sprawdzać dostępność aktualizacji artefaktów z określonej grupy z maven-central-repo?

Pracuję nad dość dużym projektem Mavena. Mamy prawdopodobnie około 70 pojedynczych artefaktów, które są z grubsza podzielone na dwie biblioteki współdzielonego kodu i może dziesięć aplikacji, które ich używają. Wszystkie te elementy znajdują się w przestrzeni nazw com.mycompany.*.

Przez większość czasu korzystamy z kompilacji migawek. Tak więc, aby wykonać pełną kompilację aplikacji, mógłbym najpierw zbudować projekty bibliotek, aby zostały zainstalowane w moim lokalnym repozytorium (jak powiedzmy mycompany-libname-2.4-SNAPSHOT.jar).

Problem w tym, że kiedy zaczynam budować aplikacje. Z jakiegoś powodu Maven chce sprawdzić dwa główne repozytoria publiczne (maven-net-repo i java-net-repo) pod kątem aktualizacji wszystkich mycompany-*-SNAPSHOT.jarartefaktów. Oczywiście ich tam nie ma i wszystko w końcu wraca do wersji, które właśnie zbudowałem w moim lokalnym repozytorium, ale chciałbym, aby Maven przestał to robić, ponieważ (a) sprawia, że ​​czuję się jak zła sieć. Obywatel za ciągłe sprawdzanie tych repozytoriów pod kątem rzeczy, których nigdy tam nie będzie, oraz (b) dodaje niepotrzebne i irytujące opóźnienia sieciowe do mojego procesu kompilacji.

Przez większość czasu korzystałem z Mavena w trybie offline, aby obejść ten problem, ale nie jest to idealne rozwiązanie, ponieważ czasami zależność od biblioteki publicznej zostanie zaktualizowana. Poszukuję więc rozwiązania, które spowoduje, że Maven nie będzie sprawdzał aktualizacji z danych repozytoriów pod kątem artefaktów spełniających określone kryteria - w tym przypadku byłbym szczęśliwy, gdyby Maven zignorował wersje SNAPSHOT lub artefakty, które były w com.mycompanynazw.

Tag updatePolicy nie działał dla mnie. Jednak Rich Seller wspomniał, że migawki i tak powinny być wyłączone, więc poszukałem dalej i zauważyłem, że dodatkowe repozytorium, które dodałem do mojego settings.xml, faktycznie powoduje problem. Dodanie sekcji migawek do tego repozytorium w moim settings.xml załatwiło sprawę!

<repository>
    <id>jboss</id>
    <name>JBoss Repository</name>
    <url>http://repository.jboss.com/maven2</url>
    <snapshots>
        <enabled>false</enabled>
    </snapshots>
</repository>

Możesz także użyć -olub --offlinew wierszu poleceń mvn, co spowoduje przełączenie mavena w „tryb offline”, aby nie sprawdzał dostępności aktualizacji. Otrzymasz ostrzeżenie, że nie możesz pobrać zależności, które nie znajdują się jeszcze w lokalnym repozytorium, ale nic wielkiego.

Coś, co jest teraz dostępne również w Maven, jest

mvn goal --no-snapshot-updates

lub w skrócie

mvn goal -nsu

Aktualizacja: prawdopodobnie powinienem był zacząć od tego, ponieważ twoje projekty to SNAPSHOT. Jest to część semantyki SNAPSHOT, którą Maven będzie sprawdzać dostępność aktualizacji dla każdej kompilacji. Bycie SNAPSHOTem oznacza, że ​​jest niestabilny i podlega zmianom, dlatego należy sprawdzać aktualizacje. Warto jednak zauważyć, że Maven super POM konfiguruje centralę tak, aby mieć wyłączone migawki, więc Maven nie powinien nigdy sprawdzać aktualizacji dla SNAPSHOTów na centralnym, chyba że nadpisałeś to we własnym pom / ustawieniach.

Możesz skonfigurować Mavena do korzystania z serwera lustrzanego dla centralnego repozytorium, co spowoduje przekierowanie wszystkich żądań, które normalnie trafiłyby do centralnego, do twojego wewnętrznego repozytorium.

W pliku settings.xml można dodać coś takiego, aby ustawić swoje wewnętrzne repozytorium jako serwer lustrzany dla centralnego:

<mirrors>
  <mirror>
    <id>ibiblio.org</id>
    <name>ibiblio Mirror of http://repo1.maven.org/maven2/</name>
    <url>http://path/to/my/repository</url>
    <mirrorOf>central</mirrorOf>
  </mirror>
</mirrors>

Jeśli używasz menedżera repozytorium, takiego jak Nexus, do wewnętrznego repozytorium. Możesz skonfigurować repozytorium proxy dla serwera proxy centralnego, tak aby wszelkie żądania, które normalnie trafiałyby do centralnego, są zamiast tego wysyłane do repozytorium proxy (lub grupy repozytoriów zawierającej proxy), a kolejne żądania są buforowane w wewnętrznym menedżerze repozytoriów. Możesz nawet ustawić limit czasu pamięci podręcznej proxy na -1, więc nigdy nie będzie żądał zawartości z centrali, która jest już w repozytorium proxy.

Bardziej podstawowym rozwiązaniem, jeśli pracujesz tylko z lokalnymi repozytoriami, jest ustawienie updatePolicy dla centralnego repozytorium na „nigdy”, co oznacza, że ​​Maven będzie sprawdzać tylko artefakty, których nie ma jeszcze w lokalnym repozytorium. W razie potrzeby można to zmienić w wierszu poleceń, używając przełącznika -U, aby zmusić Mavena do sprawdzania dostępności aktualizacji.

Skonfigurowałbyś repozytorium (w swoim pom lub profilu w settings.xml) w następujący sposób:

<repository>
  <id>central</id>
  <url>http://repo1.maven.org/maven2</url>
  <updatePolicy>never</updatePolicy>
</repository>

Bardzo prosty :

W pliku nadrzędnym Super POM lub setting.xml użyj pliku

        <repository>
        <id>central</id>
        <releases>
            <updatePolicy>never</updatePolicy>
        </releases>
        <snapshots>
            <updatePolicy>never</updatePolicy>
        </snapshots>
        <url>http://repo1.maven.org/maven2</url>
        <layout>legacy</layout>
    </repository>

To moje wskazówki

Miałem kłopoty podobne do tego,

<repository>
    <id>java.net</id>
    <url>https://maven-repository.dev.java.net/nonav/repository</url>
    <layout>legacy</layout>
</repository>
<repository>
    <id>java.net2</id>
    <url>https://maven2-repository.dev.java.net/nonav/repository</url>
</repository>

Ustawienie updatePolicy na „nigdy” nie zadziałało. Usunięcie tego repozytorium było sposobem, w jaki to rozwiązałem. ps: Śledziłem ten samouczek dotyczący usług internetowych (przy okazji, prawdopodobnie najlepszy samouczek dla ws dla java)