2017-12-13 137 views
11

zbudować projekt na gitlab CIjava.lang.IllegalStateException: Dex Archives: Ustawienie rozszerzenia .DEX tylko dla plików .class

./gradlew assembleDebug --stacktrace 

a czasami zgłasza błąd:

FAILURE: Build failed with an exception. 
* What went wrong: 
Execution failed for task ':app:transformClassesWithDexBuilderForDebug'. 
> com.android.build.api.transform.TransformException: java.lang.IllegalStateException: Dex archives: setting .DEX extension only for .CLASS files 

At mój lokalny komputer działa poprawnie.

Kotlin jest wersja 1.2

multidex jest włączona

Co jest przyczyną tego błędu?

+0

czy umożliwiasz mutlidex true i added library dla mutlidex? –

+0

Tak, edytowałem pytanie –

+0

@ m.myalkin Znaleziono jakieś rozwiązanie? – AndiGeeky

Odpowiedz

6

Wygląda na to, że znalazłem rozwiązanie. Na build chwili Gradle pokazywał ostrzeżenia dla mnie:

Configuration 'compile' in project ':app' is deprecated. Use 'implementation' instead. 

app: 'androidProcessor' dependencies won't be recognized as kapt annotation processors. Please change the configuration name to 'kapt' for these artifacts: 'com.arello-mobile:moxy-compiler:1.5.3' and apply the kapt plugin: "apply plugin: 'kotlin-kapt'". 

popełniłem błąd ortograficzny i zapomniał usunąć niepotrzebne annotationProcessor do biblioteki:

annotationProcessor "com.arello-mobile:moxy-compiler:$moxyVersion" 
kapt "com.arello-mobile:moxy-compiler:$moxyVersion" 

Więc usunąłem pierwszą linię.

Po tym czasie zastosowałem wtyczkę kapt apply plugin: 'kotlin-kapt' i naprawiłem kilka błędów kompilacji w kodzie po nim.

Po tym wszystkim zdałem sobie sprawę, że zapomniałem zastąpić compile na implementation w niektórych miejscach. To dziwne, ale bez niego kompilacja nie zadziałała.

Ta zmiana naprawia moją kompilację błędów.

-1

znajdą tutaj rozwiązanie tego problemu,

defaultConfig { 
     ... 
     minSdkVersion 14 
     targetSdkVersion 21 
     ... 

     // Enabling multidex support. 
     multiDexEnabled true 
    } 
dependencies { 
    compile 'com.android.support:multidex:1.0.0' 
} 
+0

Włączyłem już multidex w projekcie –

+0

Czy dodałeś wielowątkowe zależności, jak na I napisał w kodzie? –

+0

Tak, oczywiście, użyłem 'com.android.support: multidex: 1.0.2' –

1

Konfigurowanie multidexing nie rozwiązać ten problem dla mnie.

Jednak udało mi się znaleźć rozwiązanie ... w pewnym sensie. Zasadniczo wymagało to utworzenia żądania pobrania dla drugiej gałęzi z tego samego zatwierdzenia, co kompilacja, która uległa awarii. Kompilacja dla tego żądania ściągania powiodła się, a następnie Bitbucket pomyślał, że pierwotne żądanie ściągnięcia było w porządku i umożliwiło nam scalenie, mimo że nie wprowadziliśmy żadnych zmian w tej gałęzi. Jest tam trochę niewyjaśnionego dziwactwa, ale technika zadziałała.

Oto jak to zrobiłem:

Załóżmy, że oddział, który zawodzi nazywa bad-branch.

Utworzono nowy oddział o nazwie bad-branch-copy dla zatwierdzenia, które było powszechne między bad-branch i develop. Następnie połączyłem bad-branch w bad-branch-copy. Końcowym rezultatem tego było szybkie przewijanie do przodu, tak że bad-branch-copy zakończyło się tym samym zatwierdzeniem, co bad-branch. Spodziewałem się osobnego zatwierdzenia, więc wynik ten zaskoczył mnie, ale i tak chwytałem się słomek, więc szedłem dalej.

Następnie wepchnąłem bad-branch-copy do GitHub i utworzyłem żądanie ściągnięcia od bad-branch-copy do develop. Wywołało to kompilację opartą na bad-branch-copy ->develop, która zakończyła się pomyślnie.

W tym momencie buddybuild pokazał udaną kompilację na bad-branch-copy ->develop i nadal wykazywał awarię na bad-branch ->develop. Jednak Bitbucket pokazał udaną kompilację na żądanie pobrania dla bad-branch. Tak, to prawda: buddybuild pokazał awarię, ale Bitbucket powiedział, że wszystko jest w porządku.

Wtedy byliśmy w stanie połączyć żądanie ściągnięcia bad-branch i wszystko było dobrze ze światem. Proszę, nie pytaj mnie dlaczego, nie odpowiem. :)

Myślę, że to samo może być osiągnięte z

git checkout bad-build 
git checkout -b bad-build-copy 
git push origin bad-build-copy 

następnie tworząc prośbę popytu na złe-build-kopii.

15

./gradlew clean Naprawiono ten sam błąd dla mnie.

0

Udało mi się usunąć problem, zamykając i ponownie uruchamiając system Android Studio. Być może nawet projekt przebudowy też by to zrobił (chociaż tego nie próbowałem).

0

powyższa odpowiedź jest w większości rację, ale w moim przypadku, ja dostać ten wyjątek, kiedy skrzynia sama nazwa java i Kotlin plik następnie usuwa jeden z nich.

Rozwiązaniami są: po prostu Build -> Clean Project mój projekt i to działa. Mój projekt umożliwił także multiDex.

defaultConfig { 
     ... 
     // Enabling multidex support. 
     multiDexEnabled true 
    }