Jedna z twoich zależności wymusza aktualizację wersji guava. Użyj opcji gradle dependencies
, aby zlokalizować bibliotekę, która eksmituje twoją wersję.
Problem polega na tym, że jeśli zmusisz go do użycia 14.0.1, inna biblioteka może nie działać poprawnie. Czy nie możesz po prostu użyć wersji 17.0 jako swojej zależności?
Zamiast utrzymywać indywidualne numery wersji w build.gradle, używam pliku dependencies.gradle, który będzie mapował numery wersji i wciągał je do build.gradle. W ten sposób muszę utrzymać tylko jedną wersję guava. Więc przykładem będzie:
dependencies.gradle
ext {
ver = [
guava: '14.0.1'
]
}
a następnie w pliku build.gradle można mieć:
apply from: "dependencies.gradle"
dependencies {
compile group: 'com.google.guava', module: 'guava', version: ver.guava
compile group: 'com.google.guava', module: 'guava-gwt', version: ver.guava
}
wtedy, kiedy chce się przenieść do 17,0 Muszę tylko zmienić dependencies.gradle.
jestem także zdecydowanym fanem ustawienie przechodnie zależności false z
configurations.compile { transitive = false }
ten sposób nie mają pewne zależności eksmitowany w czasie kompilacji, choć może masz problem w czasie wykonywania, jeśli biblioteka eksmisji nie jest w pełni kompatybilny wstecz. Spójrzmy prawdzie w oczy, jeśli piszesz kod, powinieneś wiedzieć, jakich bibliotek używasz i powinieneś jasno mówić o swoich zależnościach. Chroni Cię przed jedną z twoich zależności uaktualniających i denerwujących cię.
Gdzie umieścić to w pliku gradle? Na dole bloku? –
Nadal dostaję błędy takie jak: 'Wykonanie nie powiodło się dla zadania ': transformClassesWithJarMergingForDebug'. > com.android.build.api.transform.TransformException: java.util.zip.ZipException: duplikat wpisu: com/google/android/gms/gcm/GoogleCloudMessaging $ 1.class' –
@IgorGanapolsky Lokalizacja nie ma znaczenia, ale umieściłbym go blisko szczytu. – cmcginty