Jak powiedzieć Mavenowi, aby używał najnowszej wersji zależności?

Teraz wiem, że ten temat jest stary, ale czytając pytanie i OP dostarczoną odpowiedź wydaje się, że wtyczka Maven Versions rzeczywiście mogła być lepszą odpowiedzią na jego pytanie:

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

• versions:use-latest-versions przeszukuje pom dla wszystkich wersji które były nowszą wersją I zastępuje je najnowszymi wersja.
• versions: use-latest-releases przeszukuje pom dla wszystkich bez migawki wersje, które były nowsze wydania i zastępuje je najnowsza wersja.
• wersje: update-properties aktualizuje właściwości zdefiniowane w projekt tak, aby odpowiadały najnowsza dostępna wersja specyficzne zależności. Może to być przydatne, jeśli zestaw zależności wszystkie muszą być zablokowane do jednej wersji.

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

• wersje: display-dependency-updates skanuje a zależności projektu i tworzy raport z tych zależności, które mają nowsze Dostępne wersje.
• wersje: display-plugin-updates skanuje wtyczki projektu i tworzy raport z tych wtyczek które mają dostępne nowsze wersje.
• wersje: update-parent aktualizuje sekcję nadrzędną projektu tak że odwołuje się do najnowszych dostępna wersja. Na przykład, jeśli używasz firmowego root POM, to cel może być pomocny, jeśli potrzebujesz upewnij się, że jesteś korzystanie z najnowszych wersja korporacyjnego root POM.
• wersje: update-child-modules aktualizuje sekcję nadrzędną Moduły dziecięce projektu tak aby wersja pasuje do wersji obecny projekt. Na przykład, jeśli mieć agregator pom, który jest również rodzica dla projektów, które to Agregaty i dzieci i wersje nadrzędne się zsynchronizować, to mojo może pomóc naprawić wersje Moduły dziecięce. (Uwaga Może być konieczne wywołaj Mavena z opcją-n w aby uruchomić ten cel, jeśli twój projekt jest tak zepsuty, że nie można zbudować ze względu na wersję mis-match).
• wersje: lock-snapshots przeszukuje POM w poszukiwaniu all-SNAPSHOT wersje i zastępuje je aktualna wersja znacznika czasu tego - Migawka, np.-20090327.172306-4
• wersje: unlock-snapshots przeszukuje pom pod kątem wszystkich znaczników czasu zablokowane wersje migawek i zastępuje z-migawka.
• wersje: resolve-ranges znajduje zależności z wykorzystaniem zakresów wersji i rozwiązuje zakres do określonego wersja używana.
• versions: use-releases przeszukuje pom w poszukiwaniu wszystkich wersji migawkowych które zostały wydane i zastępują ich z odpowiednim wydaniem wersja.
• versions:use-next-releases przeszukuje pom pod kątem wszystkich nie-migawek wersje, które były nowsze wydania i zastępuje je następna wersja.
• versions: use-next-versions pom dla wszystkich wersji które były nowszą wersją I zastępuje je następną wersją.
• wersje: commit usuwa pom.xml.wersje plików Packup. Formularze jedna połowa wbudowanego " biednego człowieka SCM".
• wersje: revert przywraca pom.pliki xml z pom.xml.wersje plików Packup. Formularze jedna połowa wbudowanego " biednego człowieka SCM".

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

Proszę spojrzeć na tę stronę (sekcja "zakresy wersji zależności"). To, co możesz chcieć zrobić, to coś w stylu

<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 możesz zawsze chcieć najnowszej wersji . Szczególnie jeśli wykonujesz ciągłe wdrażanie (czasami mamy jakieś 5 wydań dziennie) i nie chcesz robić projektu wielomodułowego.

To, co robię, to zmuszanie Hudsona/Jenkinsa do wykonywania następujących czynności dla każdej budowy:

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

To znaczy używam wersji plugin i SCM plugin do aktualizacji zależności, a następnie sprawdzić go do kontroli źródła. Tak, pozwoliłem mojemu informatorowi zrobić SCM checkins (co i tak musisz zrobić dla wtyczki wydania maven).

Będziesz chciał skonfigurować wtyczkę wersji, aby aktualizować 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 release do wydania, które zajmuje się-SNAPSHOT i potwierdza, że istnieje Wersja release-SNAPSHOT (co jest ważne).

Jeśli zrobisz to, co ja, otrzymasz najnowszą wersję dla wszystkich kompilacji migawek i najnowszą wersję dla kompilacji wydań. Twoje budowle również będą powtarzalne.

Update

Zauważyłem kilka komentarzy pytających o szczegóły tego workflow. Powiem, że nie używamy już tej metody, a głównym powodem, dla którego wtyczka maven versions jest wadliwa i ogólnie jest z natury wadliwa.

Jest wadliwy, ponieważ aby uruchomić wtyczkę versions, aby dostosować wersje, wszystkie istniejące wersje muszą istnieć, aby pom działał poprawnie. To jest wtyczka wersji nie może zaktualizować do najnowszej wersji niczego, jeśli nie może znajdź wersję wskazaną w pom. Jest to raczej irytujące, ponieważ często czyścimy stare wersje ze względu na miejsce na dysku.

Naprawdę potrzebujesz oddzielnego narzędzia od Mavena, aby dostosować wersje (więc nie zależy ci na poprawnym uruchomieniu pliku pom). Napisałem takie narzędzie w prostym języku jakim jest Bash. Skrypt zaktualizuje wersje, takie jak wtyczka wersji i sprawdzi Pom z powrotem do kontroli źródła. Działa również 100x szybciej niż wtyczka wersji mvn. Niestety nie jest napisany w sposób do użytku publicznego, ale jeśli ludzie są zainteresowani, mogę to zrobić i umieścić go w gist lub github.

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

Mamy około 20 projektów we własnych repozytoriach z własnymi zadaniami jenkins]}
1. kiedy wydajemy wtyczkę wydania maven jest używany. Przepływ pracy jest omówiony w dokumentacji wtyczki. Wtyczka do wydania Mavena jest do bani (i Jestem miły), ale to działa. Pewnego dnia planujemy zastąpienie tej metody czymś bardziej optymalnym.
2. kiedy jeden z projektów zostanie wydany, jenkins uruchomi specjalne zadanie, które nazwiemy zadaniem update all versions (skąd jenkins wie, że jego wydanie jest skomplikowane, ponieważ wtyczka wydania Mavena Jenkinsa również jest dość gówniana).
3. zadanie update all versions wie o wszystkich 20 projektach. Jest to właściwie agregator pom, aby być specyficznym dla wszystkich projekty w sekcji Moduły w kolejności zależności. Jenkins uruchamia nasz magiczny groovy / bash foo, który ściągnie wszystkie projekty zaktualizuje wersje do najnowszej, a następnie sprawdzi poms (ponownie w kolejności zależności w oparciu o sekcję Moduły).
4. dla każdego projektu, jeśli pom się zmienił (z powodu zmiany wersji w jakiejś zależności) jest sprawdzany, a następnie natychmiast ping jenkins uruchamia odpowiednie zadanie dla tego projektu (ma to na celu zachowanie kolejności budowania zależności w przeciwnym razie jesteś na łasce harmonogramu ankiety SCM).

W tym momencie jestem zdania, że dobrze jest mieć wersję release i auto jako oddzielne narzędzie od ogólnego budowania.

Teraz możesz pomyśleć, że maven jest do bani z powodu problemów wymienionych powyżej, ale w rzeczywistości byłoby to dość trudne w przypadku narzędzia do budowania, które nie ma deklaratywnej łatwej do przetworzenia składni extendable (aka XML).

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

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

Dependencies' version element definiuje wymagania wersji, używany do obliczania efektywnej wersji zależności. Wymagania wersji mają następującą składnię:

• W zależności od wersji 1.0 (tylko zalecenie, jeśli pasuje do wszystkich innych zakresów zależności)
• [1.0]: "Hard" Wymaganie na 1.0
• (,1.0]: x
• [1.2,1.3]: 1.2
• [1.0,2.0): 1.0
• [1.5,): x > = 1.5
• (,1.0],[1.2,): x = 1.2; wiele zestawów jest oddzielonych przecinkami
• (,1.1),(1.1,): wyklucza to 1.1 (np. jeśli wiadomo, że nie praca w połączeniu z tą biblioteką)

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

Czy jest możliwe, że zależy ci na wersjach rozwojowych, które oczywiście bardzo się zmieniają podczas rozwoju?

Zamiast zwiększać wersję wydań deweloperskich, możesz po prostu użyć wersji migawkowej, którą w razie potrzeby nadpisujesz, 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 LATEST, 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

Zanim zadano to pytanie, w mavenie pojawiły się pewne problemy z zakresami wersji, ale zostały one rozwiązane w nowszych wersjach Mavena. Ten artykuł bardzo dobrze opisuje, jak działają zakresy wersji i najlepsze praktyki, aby lepiej zrozumieć, jak maven rozumie wersje: https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm#MAVEN8855

Prawda jest nawet w 3.x nadal działa, zaskakująco projekty budują i wdrażają. Ale słowo kluczowe najnowsze / RELEASE powodujące problemy w m2e i eclipse wszędzie, również projekty zależą od zależności, które wdrożone przez najnowsze / RELEASE nie rozpoznają wersji.

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

Więc wniosek jest użycie wersje-Maven-plugin jeśli może.

Czasami nie chcesz używać zakresów wersji, ponieważ wydaje się, że są one "powolne" w rozwiązywaniu zależności, zwłaszcza gdy istnieje ciągłe dostarczanie i istnieje mnóstwo wersji - głównie podczas intensywnego rozwoju.

Jednym obejściem byłoby użycie versions-Maven-plugin . Na przykład, możesz zadeklarować właściwość:

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

I dodaj wersje-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, w celu aktualizacji zależności, można trzeba realizować 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

Moje rozwiązanie w mavenie 3.5.4, użyj Nexusa, w eclipse:

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

Następnie w eclipse: atl + F5 i wybierz force update of snapshots/release

Jeśli chcesz Maven powinien używać najnowszej wersji zależności, następnie można użyć wersje Maven plugin i jak korzystać z tej wtyczki, Tim już dał dobrą odpowiedź, wykonaj jego odpowiedź .

Ale jako deweloper Nie będę polecał tego typu praktyk. Dlaczego?

ODPOWIEDŹ na pytanie dlaczego jest już podana przez Pascala Thiventa w komentarzu do pytania

Naprawdę nie polecam tej praktyki (ani używania zakresów wersji) dla sake odtwarzalności konstrukcji. Budowa, która zaczyna nagle awaria z nieznanego powodu jest o wiele bardziej irytująca niż ręczna aktualizacja numer wersji.

Polecam 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>