Jak powiedzieć Maven, aby użyła najnowszej wersji zależności?

W Maven zależności są zwykle konfigurowane w następujący sposób:

<dependency>
  <groupId>wonderful-inc</groupId>
  <artifactId>dream-library</artifactId>
  <version>1.2.3</version>
</dependency>

Teraz, jeśli pracujesz z bibliotekami, które mają częste wydania, ciągłe aktualizowanie znacznika <version> może być nieco denerwujące. Czy jest jakiś sposób, aby powiedzieć Maven, aby zawsze korzystała z najnowszej dostępnej wersji (z repozytorium)?

UWAGA:

Ta odpowiedź dotyczy tylko Maven 2! Wspomniane LATESTi RELEASEmetawersje zostały porzucone w Maven 3 „ze względu na powtarzalne wersje” ponad 6 lat temu. Zapoznaj się z tym rozwiązaniem zgodnym z Maven 3 .

Jeśli zawsze chcesz używać najnowszej wersji, Maven ma dwa słowa kluczowe, których możesz użyć jako alternatywy dla zakresów wersji. Powinieneś używać tych opcji ostrożnie, ponieważ nie masz już kontroli nad wtyczkami / zależnościami, których używasz.

Jeśli zależysz od wtyczki lub zależności, możesz użyć wartości wersji NAJNOWSZE lub ZWOLNIENIE. NAJNOWSZY odnosi się do najnowszej wydanej lub migawkowej wersji określonego artefaktu, najnowszego artefaktu wdrożonego w określonym repozytorium. RELEASE odnosi się do ostatniego wydania innego niż migawka w repozytorium. Ogólnie rzecz biorąc, nie jest najlepszą praktyką projektowanie oprogramowania, które zależy od niespecyficznej wersji artefaktu. Jeśli tworzysz oprogramowanie, możesz użyć WYDANIA lub NAJNOWSZY dla wygody, abyś nie musiał aktualizować numerów wersji, gdy zostanie wydana nowa wersja biblioteki innej firmy. Po wydaniu oprogramowania należy zawsze upewnić się, że projekt zależy od konkretnych wersji, aby zmniejszyć ryzyko kompilacji lub wpływu projektu na wersję, która nie jest pod kontrolą użytkownika.

Aby uzyskać więcej informacji, zobacz sekcję POM Składnia książki Maven . Lub zobacz ten dokument na temat zakresów wersji zależności , gdzie:

• Nawias kwadratowy ( [& ]) oznacza „zamknięty” (włącznie).
• Nawias ( (& )) oznacza „otwarty” (wyłączny).

Oto przykład ilustrujący różne opcje. W repozytorium Maven com.foo:my-foo ma następujące metadane:

<?xml version="1.0" encoding="UTF-8"?><metadata>
  <groupId>com.foo</groupId>
  <artifactId>my-foo</artifactId>
  <version>2.0.0</version>
  <versioning>
    <release>1.1.1</release>
    <versions>
      <version>1.0</version>
      <version>1.0.1</version>
      <version>1.1</version>
      <version>1.1.1</version>
      <version>2.0.0</version>
    </versions>
    <lastUpdated>20090722140000</lastUpdated>
  </versioning>
</metadata>

Jeśli wymagana jest zależność od tego artefaktu, dostępne są następujące opcje ( oczywiście można określić inne zakresy wersji , pokazując tutaj tylko odpowiednie):

Zadeklaruj dokładną wersję (zawsze rozwiąże to 1.0.1):

<version>[1.0.1]</version>

Zadeklaruj jawną wersję (zawsze rozwiąże się do 1.0.1, chyba że nastąpi kolizja, gdy Maven wybierze pasującą wersję):

<version>1.0.1</version>

Zadeklaruj zakres wersji dla wszystkich wersji 1.x (obecnie rozwiąże to 1.1.1):

<version>[1.0.0,2.0.0)</version>

Zadeklaruj otwarty zakres wersji (rozwiąże się do wersji 2.0.0):

<version>[1.0.0,)</version>

Zadeklaruj wersję jako NAJNOWSZĄ (rozwiąże się do 2.0.0) (usunięto z maven 3.x)

<version>LATEST</version>

Zadeklaruj wersję jako RELEASE (rozwiąże się do 1.1.1) (usunięto z maven 3.x):

<version>RELEASE</version>

Zauważ, że domyślnie twoje własne wdrożenia aktualizują „najnowszy” wpis w metadanych Maven, ale aby zaktualizować wpis „release”, musisz aktywować „profil wydania” z super POM Maven . Możesz to zrobić za pomocą „-Prelease-profile” lub „-DperformRelease = true”

Warto podkreślić, że każde podejście, które pozwala Maven wybrać wersje zależności (NAJNOWSZE, WYDAWANIE i zakresy wersji) może pozostawić cię otwartym na problemy z budowaniem czasu, ponieważ późniejsze wersje mogą mieć inne zachowanie (na przykład wtyczka zależności wcześniej zmieniła domyślną wartość od true do false, z mylącymi wynikami).

Dlatego ogólnie dobrym pomysłem jest zdefiniowanie dokładnych wersji w wydaniach. Jak wskazuje odpowiedź Tima, wtyczka maven-wersje-wtyczka jest przydatnym narzędziem do aktualizowania wersji zależności, w szczególności wersji: użyj najnowszych wersji i wersji: użyj celów najnowszych wydań .

Teraz wiem, że ten temat jest stary, ale po przeczytaniu pytania i dostarczonej odpowiedzi OP wydaje się, że wtyczka Maven Versions Plugin mogła być lepszą odpowiedzią na jego pytanie:

W szczególności przydatne mogą być następujące cele:

• wersje: użyj najnowszych wersji przeszukuje pom w poszukiwaniu wszystkich wersji, które były nowszymi wersjami i zastępuje je najnowszą wersją.
• wersje: use-latest-releases przeszukuje pom w poszukiwaniu wszystkich wersji innych niż SNAPSHOT, które były nowsze, i zastępuje je najnowszą wersją.
• wersje: aktualizacja-właściwości aktualizuje właściwości zdefiniowane w projekcie, tak aby odpowiadały najnowszej dostępnej wersji określonych zależności. Może to być przydatne, jeśli pakiet zależności musi być zablokowany w jednej wersji.

Przewidziane są również następujące inne cele:

• wersje: aktualizacje zależne od wyświetlania skanują zależności projektu i generują raport o zależnościach, w których dostępne są nowsze wersje.
• wersje: display-plugin-updates skanuje wtyczki projektu i generuje raport o tych wtyczkach, które mają dostępne nowsze wersje.
• wersje: aktualizacja-rodzic aktualizuje sekcję nadrzędną projektu, tak aby odwoływała się do najnowszej dostępnej wersji. Na przykład, jeśli korzystasz z głównej korporacyjnej POM, ten cel może być pomocny, jeśli musisz upewnić się, że korzystasz z najnowszej wersji korporacyjnej głównej POM.
• wersje: update-child-modules aktualizuje sekcję nadrzędną modułów potomnych projektu, aby wersja była zgodna z wersją bieżącego projektu. Na przykład, jeśli masz agregator pom, który jest również nadrzędny dla projektów, które agreguje, a wersje potomna i nadrzędna nie synchronizują się, to mojo może pomóc naprawić wersje modułów potomnych. (Uwaga: może być konieczne wywołanie Maven z opcją -N, aby uruchomić ten cel, jeśli projekt jest uszkodzony tak bardzo, że nie można go zbudować z powodu niepoprawnej wersji).
• wersje: migawki blokujące przeszukują pom w poszukiwaniu wszystkich wersji -SNAPSHOT i zastępują je bieżącą wersją znacznika czasu tego -SNAPSHOT, np. -20090327.172306-4
• wersje: odblokuj migawki przeszukuje pom w poszukiwaniu wszystkich zablokowanych wersji migawek i zamienia je na -SNAPSHOT.
• wersje: rozdzielczość-zakresów znajduje zależności przy użyciu zakresów wersji i rozwiązuje zakres dla konkretnej używanej wersji.
• wersje: use-releases przeszukuje pom w poszukiwaniu wszystkich wydanych wersji -SNAPSHOT i zastępuje je odpowiednią wersją wydania.
• wersje: use-next-releases przeszukuje pom w poszukiwaniu wszystkich wersji innych niż SNAPSHOT, które były nowsze, i zastępuje je następną wersją.
• wersje: use-next-wersje przeszukuje pom w poszukiwaniu wszystkich wersji, które były nowszymi wersjami i zastępuje je następną wersją.
• wersje: zatwierdzenie usuwa pliki pom.xml.versionsBackup. Tworzy połowę wbudowanego „Poor Man's SCM”.
• wersje: przywróć przywraca pliki pom.xml z plików pom.xml.versionsBackup. Tworzy połowę wbudowanego „Poor Man's SCM”.

Pomyślałem, że dołączę to do każdego odniesienia w przyszłości.

Proszę spojrzeć na tę stronę (sekcja „Zakresy wersji zależności”). Możesz chcieć coś takiego

<version>[1.2.3,)</version>

Te zakresy wersji są zaimplementowane w Maven2.

W przeciwieństwie do innych, myślę, że istnieje wiele powodów, dla których zawsze możesz chcieć najnowszej wersji. Zwłaszcza jeśli wykonujesz ciągłe wdrażanie (czasami mamy około 5 wydań dziennie) i nie chcesz wykonywać projektu wielomodułowego.

To, co robię, polega na tym, aby Hudson / Jenkins wykonał następujące czynności dla każdej kompilacji:

mvn clean versions:use-latest-versions scm:checkin deploy -Dmessage="update versions" -DperformRelease=true

To znaczy używam wtyczki wersji i wtyczki scm do aktualizacji zależności, a następnie rejestruję ją w celu kontroli źródła. Tak, pozwalam CI na sprawdzanie SCM (co i tak musisz zrobić dla wtyczki maven release).

Będziesz chciał skonfigurować wtyczkę wersji, aby aktualizowała tylko to, co chcesz:

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>versions-maven-plugin</artifactId>
    <version>1.2</version>
    <configuration>
        <includesList>com.snaphop</includesList>
        <generateBackupPoms>false</generateBackupPoms>
        <allowSnapshots>true</allowSnapshots>
    </configuration>
</plugin>

Używam wtyczki wydania, aby wykonać wydanie, które zajmuje się -SNAPSHOT i sprawdza, czy istnieje wersja -SNAPSHOT (co jest ważne).

Jeśli zrobisz to, co ja, otrzymasz najnowszą wersję dla wszystkich kompilacji migawek i najnowszą wersję dla kompilacji wersji. Twoje kompilacje będą również odtwarzalne.

Aktualizacja

Zauważyłem kilka komentarzy z pytaniem o specyfikę tego przepływu pracy. Powiem, że nie używamy już tej metody i główny powód, dla którego wtyczka wersji maven jest wadliwa i ogólnie jest wadliwa.

Jest wadliwy, ponieważ aby uruchomić wtyczkę wersji w celu dostosowania wersji, wszystkie istniejące wersje muszą istnieć, aby pom działał poprawnie. Oznacza to, że wtyczka wersji nie może zaktualizować się do najnowszej wersji czegokolwiek, jeśli nie może znaleźć wersji wymienionej w pom. Jest to w rzeczywistości dość denerwujące, ponieważ często usuwamy stare wersje ze względu na miejsce na dysku.

Naprawdę potrzebujesz oddzielnego narzędzia od maven, aby dostosować wersje (więc nie zależy od poprawnego działania pliku pom). Napisałem takie narzędzie w skromnym języku, jakim jest Bash. Skrypt zaktualizuje wersje takie jak wtyczka wersji i sprawdzi pom ponownie kontrolę źródła. Działa również 100 razy szybciej niż wtyczka wersji mvn. Niestety nie jest napisany w sposób do użytku publicznego, ale jeśli ludzie są zainteresowani, mógłbym to zrobić i umieścić to w gistubie lub githubie.

Wracając do przepływu pracy, ponieważ niektóre komentarze pytały o to, co robimy:

1. Mamy około 20 projektów w ich własnych repozytoriach z własnymi zadaniami Jenkinsa
2. Po wydaniu używana jest wtyczka maven release. Przepływ pracy jest opisany w dokumentacji wtyczki. Wtyczka maven wydaje się do bani (a ja jestem uprzejma), ale działa. Pewnego dnia planujemy zastąpić tę metodę czymś bardziej optymalnym.
3. Kiedy jeden z projektów zostanie wydany, Jenkins następnie uruchomi specjalne zadanie, nazwiemy aktualizację zadaniem wszystkich wersji (skąd Jenkins wie, że wydanie jest skomplikowane, częściowo dlatego, że wtyczka maven jenkins wydaje się dość gówniana).
4. Zadanie aktualizacji wszystkich wersji wie o wszystkich 20 projektach. W rzeczywistości jest to agregator pom, który jest specyficzny dla wszystkich projektów w sekcji modułów w kolejności zależności. Jenkins uruchamia nasz magiczny groovy / bash foo, który ściągnie wszystkie projekty, zaktualizuje wersje do najnowszej wersji, a następnie sprawdzi poms (ponownie wykonane w kolejności zależności na podstawie sekcji modułów).
5. Dla każdego projektu, jeśli pom zmienił się (z powodu zmiany wersji w pewnej zależności), jest on rejestrowany, a następnie natychmiast pingujemy jenkins, aby uruchomić odpowiednie zadanie dla tego projektu (ma to na celu zachowanie kolejności zależności kompilacji, w przeciwnym razie jesteś na łasce harmonogramu odpytywania SCM).

W tym momencie uważam, że dobrze jest, aby wydanie i wersja automatyczna były odrębnym narzędziem od ogólnej wersji.

Teraz myślisz Maven rodzaju bani z powodu wyżej wymienionych problemów, ale to faktycznie byłoby dość trudne z narzędziem budowy, który nie posiada deklaratywny łatwe do analizowania wysuwaną składni XML (aka).

W rzeczywistości dodajemy niestandardowe atrybuty XML poprzez przestrzenie nazw, aby pomóc podpowiedzieć skryptom bash / groovy (np. Nie aktualizuj tej wersji).

Składnia zależności znajduje się w dokumentacji specyfikacji wymagań wersji zależności . Tutaj jest dla kompletności:

versionElement zależności określa wymagania dotyczące wersji, które służą do obliczania skutecznej wersji zależności. Wymagania dotyczące wersji mają następującą składnię:

• 1.0: Wymaganie „miękkie” w wersji 1.0 (tylko zalecenie, jeśli pasuje do wszystkich innych zakresów zależności)
• [1.0]: Wymaganie „twarde” w wersji 1.0
• (,1.0]: x <= 1,0
• [1.2,1.3]: 1,2 <= x <= 1,3
• [1.0,2.0): 1,0 <= x <2,0
• [1.5,): x> = 1,5
• (,1.0],[1.2,): x <= 1,0 lub x> = 1,2; wiele zestawów jest oddzielonych przecinkami
• (,1.1),(1.1,): wyklucza to 1.1 (na przykład, jeśli wiadomo, że nie działa w połączeniu z tą biblioteką)

W twoim przypadku możesz zrobić coś takiego <version>[1.2.3,)</version>

Czy jesteś prawdopodobnie zależny od wersji programistycznych, które oczywiście bardzo się zmieniają podczas programowania?

Zamiast zwiększać wersję wydań programistycznych, możesz po prostu użyć migawki, którą w razie potrzeby zastępujesz, co oznacza, że ​​nie będziesz musiał zmieniać tagu wersji przy każdej drobnej zmianie. Coś w stylu 1.0-SNAPSHOT ...

Ale może próbujesz osiągnąć coś innego;)

Kto kiedykolwiek używa NAJNOWSZY, upewnij się, że masz -U, w przeciwnym razie najnowsza migawka nie zostanie pobrana.

mvn -U dependency:copy -Dartifact=com.foo:my-foo:LATEST
// pull the latest snapshot for my-foo from all repositories

Do czasu postawienia tego pytania pojawiły się pewne zagięcia z zakresami wersji w maven, ale zostały one rozwiązane w nowszych wersjach maven. W tym artykule bardzo dobrze przedstawiono działanie zakresów wersji i najlepsze praktyki, aby lepiej zrozumieć, w jaki sposób maven rozumie wersje: https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm#MAVEN8855

Prawda jest taka, że ​​nawet w wersji 3.x nadal działa, co zaskakujące, projekty budują i wdrażają. Ale słowo kluczowe NAJNOWSZE / ZWOLNIENIE powodujące problemy w m2e i zaćmieniu w każdym miejscu, TAKŻE projekty zależą od zależności, która wdrożona przez NAJNOWSZE / WYDANIE nie rozpoznaje wersji.

Będzie to również powodować problemy, jeśli spróbujesz zdefiniować wersję jako właściwość i odwołać się do niej gdzie indziej.

Podsumowując, skorzystaj z pluginu-wersji-maven, jeśli możesz.

Czasami nie chcesz używać zakresów wersji, ponieważ wydaje się, że są one „powolne”, aby rozwiązać twoje zależności, szczególnie gdy istnieje ciągłe dostarczanie i jest mnóstwo wersji - głównie podczas ciężkiego rozwoju.

Jednym z obejść byłoby użycie wtyczki version-maven . Na przykład możesz zadeklarować właściwość:

<properties>
    <myname.version>1.1.1</myname.version>
</properties>

i dodaj wersję-maven-plugin do pliku pom:

<build>
    <plugins>
        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>versions-maven-plugin</artifactId>
            <version>2.3</version>
            <configuration>
                <properties>
                    <property>
                        <name>myname.version</name>
                        <dependencies>
                            <dependency>
                                <groupId>group-id</groupId>
                                <artifactId>artifact-id</artifactId>
                                <version>latest</version>
                            </dependency>
                        </dependencies>
                    </property>
                </properties>
            </configuration>
        </plugin>
    </plugins>
</build>

Następnie, aby zaktualizować zależność, musisz wykonać cele:

mvn versions:update-properties validate

Jeśli istnieje wersja nowsza niż 1.1.1, powie Ci:

[INFO] Updated ${myname.version} from 1.1.1 to 1.3.2

Jeśli chcesz, aby Maven powinien używać najnowszej wersji zależności, możesz użyć wtyczki Versions Maven i jak korzystać z tej wtyczki, Tim już udzielił dobrej odpowiedzi, postępuj zgodnie z jego odpowiedzią .

Ale jako programista nie będę polecał tego typu praktyk. DLACZEGO?

odpowiedz na pytanie, dlaczego Pascal Thivent podał już w komentarzu do pytania

Naprawdę nie polecam tej praktyki (ani używania zakresów wersji) ze względu na odtwarzalność kompilacji. Kompilacja, która nagle kończy się niepowodzeniem z nieznanego powodu, jest o wiele bardziej irytująca niż ręczna aktualizacja numeru wersji.

Polecę ten rodzaj praktyki:

<properties>
    <spring.version>3.1.2.RELEASE</spring.version>
</properties>

<dependencies>

    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-core</artifactId>
        <version>${spring.version}</version>
    </dependency>

    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-context</artifactId>
        <version>${spring.version}</version>
    </dependency>

</dependencies>

jest łatwy w utrzymaniu i debugowaniu. Możesz zaktualizować swój POM w mgnieniu oka.

MOJE rozwiązanie w maven 3.5.4, użyj nexusa, w zaćmieniu:

<dependency>
    <groupId>yilin.sheng</groupId>
    <artifactId>webspherecore</artifactId>
    <version>LATEST</version> 
</dependency>

następnie w Eclipse: atl + F5i wybierzforce update of snapshots/release

mi to pasuje.