Gradle - pobieranie najnowszej wersji zależności

94

Jaki byłby najłatwiejszy sposób, aby powiedzieć, Gradleco następuje:

Pobierz zależność „junit” i pobierz jej najnowszą wersję.

Zarządzanie repozytoriami Maven i Ivy to dla mnie nowość. Wypróbowałem następujące kroki i skutkują Could not resolve dependency ...błędem:

Pisz compile "junit:junit:latest.release"z repozytoriami ustawionymi na same mavenCentral() (jednak działa, jeśli powiem „junit: junit: 4.10”).

Napisz compile "junit:junit:latest.release"z repozytorium w następujący sposób:

ivy {
    // I also tried 'http://maven.org' and other possible variants.           
    url "http://repo1.maven.org" 
    layout "maven"
}

Podjęto próbę użycia repozytorium Spring Source Ivy:

ivy {
    artifactPattern "http://repository.springsource.com/ivy/libraries/release/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]"
    ivyPattern "http://repository.springsource.com/ivy/libraries/release/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]"
}

Może coś źle zrozumiałem. Dlaczego uzyskanie najnowszej wersji zależności miałoby być tak trudnym zadaniem?

— Yippie-Ki-Yay
źródło

Wersja dynamiczna może być zastępczym do najnowszej dostępnej wersji, latest.integration. dokumentacja gradle dla wersji dynamicznych

— Bhavik

49

Gradle obecnie nie obsługuje Mavena RELEASE(który jest rzadko używany i przestarzały), ale obsługuje Ivy latest.release. Jednak ogólne zalecenie polega na tworzeniu na podstawie dokładnych wersji. W przeciwnym razie kompilacja może stać się loterią.

— Peter Niederwieser
źródło

Maven również nie obsługuje RELEASE. Tylko stałe numery wersji.

— khmarbaise

10

Sprawdziłem dwukrotnie. Maven obsługuje RELEASE, zarówno w wersji 2, jak i 3.

— Peter Niederwieser

Masz rację. Pomyliłem się, że z wersjami wtyczek, ponieważ dla Maven 3 nie pozwala już na RELEASE / LATEST. Ale używanie takich identyfikatorów wersji jest oczywiście złą praktyką.

— khmarbaise

Artefakt w repozytorium Maven Release to taki, który przeszedł wszystkie możliwe testy automatyczne (i być może ręczne). Proces ten powinien obejmować sprawdzanie zgodności API, testy regresyjne i tak dalej. Dlaczego więc konstrukcja może stać się loterią? Tylko w przypadku „zwalniania” artefaktów, które nie zostały wystarczająco przetestowane.

— RCross

2

Grade obsługuje „najnowszą wersję” (ale nie „RELEASE”). Jest to niezwykle przydatne, aby zapewnić, że twoje własne biblioteki wewnętrzne są w najnowszej, sprawdzonej wersji - oczywiście nigdy nie zalecałbym jej używania w bibliotekach zewnętrznych / zewnętrznych z tego samego powodu, który Peter sugeruje powyżej.

— Rross

259

Czasami może być całkiem przydatne pobranie najnowszej wersji - na przykład jeśli często udostępniasz własne zależności.

Możesz pobrać najnowszą wersję, taką jak

compile "junit:junit:+"

lub lepiej określ przynajmniej wersję główną, taką jak

compile "junit:junit:4.+"

— jmruc
źródło

28

tak dla przypomnienia: to rzeczywiście powinny być cudzysłowy! code 'junit:junit:4.+'

— Używałem

1

@azonli Wydaje się, że działa dla mnie z pojedynczymi cudzysłowami, przynajmniej w przypadku lokalnych zależności. Jaki błąd otrzymujesz?

— David Moles

3

czy nie powinno to być „testCompile” zamiast „compile”? ponieważ artefakt nie jest potrzebny w wydaniu

— Martin Dürrmeier

6

Nie zawsze potrzebujesz odtwarzalnej wersji.

— Lakatos Gyula,

2

@SimonForsberg ... To prawda, jednak gdy jesteś niedopracowany, możesz chcieć (a) postępować zgodnie z najnowszymi trendami lub (b) upewnić się, że poprawki błędów dla v 4.+są aktualne dla twojego projektu. Kiedy osiągniesz etap Alpha, Beta, -RC lub -RELEASE; Całkowicie się zgadzam, że musisz „ przygwoździć ” te wersje do tyczki. Używam properties' file to set version specifiers: kompilacji "junit: junit: $ { junitVer }" `.

— będzie

25

Sprawdź wtyczkę Gradle-Versions-Plugin. Robi dokładnie to, co chcesz: https://github.com/ben-manes/gradle-versions-plugin

Informacje na temat instalacji można znaleźć na stronie github. Zasadniczo musisz dodać te dwie linie do pliku build.gradle - projektu:

apply plugin: 'com.github.ben-manes.versions'

buildscript {
    [...]
    dependencies {
        classpath 'com.github.ben-manes:gradle-versions-plugin:0.8'
        [...]
    }
}
[...]

Następnie możesz użyć wtyczki, uruchamiając to polecenie w terminalu w katalogu projektu:

./gradlew dependencyUpdates -Drevision=release

I pokaże Ci, które zależności są nieaktualne!

— electronix384128
źródło

Możesz również dodać to do skryptu inicjującego, jeśli nie chcesz, aby wtyczka była dołączana do każdego projektu. Szczegółowe informacje można znaleźć w tej odpowiedzi na inne pytanie .

— Laurence Gonsalves

co, jeśli zależności znajdują się w tym samym repozytorium, a zawsze chcesz mieć najnowszą wersję?

— Barry Kelly

8

W najnowszym podręczniku użytkownika Gradle wspomina się i wyjaśnia wersje plus logowanie:

Od 7.2. Deklarowanie zależności :

dependencies {
    compile group: 'org.hibernate', name: 'hibernate-core', version: '3.6.7.Final'
    testCompile group: 'junit', name: 'junit', version: '4.+'
}
... Skrypt kompilacji stwierdza również, że do kompilacji testów projektu wymagana jest dowolna junit> = 4.0.

Od 23.7. Jak działa rozwiązywanie zależności :

Jeśli zależność zostanie zadeklarowana jako wersja dynamiczna (np. 1. +), Gradle rozwiąże to na najnowszą dostępną wersję statyczną (np. 1.2) w repozytorium. W przypadku repozytoriów Maven odbywa się to za pomocą pliku maven-metadata.xml, podczas gdy w przypadku repozytoriów Ivy odbywa się to za pomocą listingu katalogów.

— RunninglVlan
źródło

1

Ważna wskazówka: znak + niekoniecznie oznacza najnowszą wersję. Zobacz mój komentarz powyżej.

— Harry G.

3

W Android Studio:

Jeśli używasz +dla wersji i chcesz wiedzieć, która wersja jest faktycznie używana , wybierz Projectna pasku bocznym, a poniżej External Librarieszobaczysz aktualny numer używanej wersji.

— lenooh
źródło

Czy odnosisz się do konkretnego IDE? :-)

— Inego

Inego: tak, dodałem to do odpowiedzi ;-)

— lenooh 22.04.19