Rozwiązywanie konfliktów przez Gradle nie działa z projektami Android?

Próbuję skompilować moduł, którego zależność drzewo wyglądaRozwiązywanie konfliktów przez Gradle nie działa z projektami Android?

+--- com.squareup.burst:burst-junit4:1.0.2 
| +--- com.squareup.burst:burst:1.0.2 
| \--- junit:junit:4.11 -> 4.12 
|   \--- org.hamcrest:hamcrest-core:1.3 
+--- com.android.support.test.espresso:espresso-core:2.0 
| +--- com.squareup:javawriter:2.1.1 
| +--- org.hamcrest:hamcrest-integration:1.1 
| | \--- org.hamcrest:hamcrest-core:1.1 -> 1.3 
| +--- org.hamcrest:hamcrest-library:1.1 
| | \--- org.hamcrest:hamcrest-core:1.1 -> 1.3 
| +--- com.android.support.test.espresso:espresso-idling-resource:2.0 
| +--- com.android.support.test:testing-support-lib:0.1 
| | \--- junit:junit-dep:4.10 
| |   \--- org.hamcrest:hamcrest-core:1.1 -> 1.3 
| +--- com.google.code.findbugs:jsr305:2.0.1 
| +--- javax.annotation:javax.annotation-api:1.2 
| \--- org.hamcrest:hamcrest-core:1.1 -> 1.3 
...

Jak widać istnieje konflikt hamcrest-core wersja, ale Gradle wydaje się rozpoznać konflikt i zastosowanie jej domyślną strategię „najnowszej wersji”, który jest dokładnie tym, czego chcę.

Jednak podczas próby uruchomienia assembleDebugTest (ręcznie lub za pośrednictwem Android Studio) Mam

com.android.dex.DexException: Multiple dex files define Lorg/hamcrest/MatcherAssert;

Niektóre odpowiedzi na podobne pytania sugerują exclude ing niechcianych słoików, ale ja spotkałem kilka podobnych konfliktów , i robi się trochę poza zasięgiem.

Dlaczego domyślna strategia konfliktu gradle nie usuwa automatycznie starego słoika? Czy wtyczka gradle androida tłumi tę funkcjonalność?

Źródło

2015-01-20 Daniel Lubarov

http://stackoverflow.com/questions/20989317/multiple-dex-files-define-landroid-support-v4-accessibilityservice- accessibility –

Widziałem to i rozumiem szybkie rozwiązanie. Moje pytanie brzmi: dlaczego domyślna strategia gradle nie jest używana do automatycznego usuwania słoików, jak można by się tego spodziewać po przeczytaniu [tego dokumentu] (http://www.gradle.org/docs/current/dsl/org. gradle.api.artifacts.ResolutionStrategy.html). –

może wypróbować kompilację z opcją -verbose ... znajdź miejsce, w którym konfigurations.resolutionStrategy {} jest wywoływana .... jeśli NIE zostanie wywołane, podaj własną implementację. –

Po jakimś bardziej kopanie, wydaje się, że problemem jest to, że moje drzewa zależności zawarte hamcrest-core 1.3 i 1.1 oraz hamcrest-integrationMatcherAssert został przeniesiony z hamcrest-integration do hamcrest-core między tymi wersjami.

W związku z tym gradle przeprowadzało rozwiązywanie konfliktów zgodnie z dokumentacją; był tylko konflikt między różnymi modułami, czego się nie spodziewałem.

Wymuszenie 1.3 dla wszystkich trzech modułów hamcrest zajęło się problemem.

Źródło

2015-01-21 19:15:56

jak to zrobić –

@ user1232726 zobacz https://docs.gradle.org/current/dsl/org.gradle.api.artifacts.ResolutionStrategy.html –

Rozwiązywanie konfliktów przez Gradle nie działa z projektami Android?

Odpowiedz

Powiązane problemy