Gradle 5.0: Wie man deprecated Features behebt und ein Kotlin-Projekt aktualisiert

Warum schreit Gradle "Deprecated features" und was ist dagegen zu tun?

Haben Sie jemals einen Build eines Kotlin-Projekts gestartet und eine beängstigende Meldung gesehen: Deprecated Gradle features were used in this build, making it incompatible with Gradle 5.0? Wenn ja, sind Sie nicht allein. Diese Frage hat auf Stack Overflow tausende Aufrufe gesammelt, und heute werden wir sie gründlich durchleuchten.

Stellen Sie sich vor: Sie programmieren in Kotlin, alles funktioniert, aber plötzlich wird Gradle mürrisch. Es sagt: "Hey, du verwendest alte Funktionen, die ich in Version 5.0 entfernen werde!". Das ist, als würde Ihre Lieblings-Kaffeemaschine Ihnen mitteilen, dass sie morgen keine alten Tassen mehr annimmt. Unangenehm, aber lösbar.

In diesem Artikel zeigen wir nicht nur, wie man den Fehler behebt. Wir vergleichen drei Ansätze zur Lösung: vom schnellen "Flicken"-Ansatz bis zum professionellen Refactoring. Sie erfahren, warum Gradle Ihren Code als veraltet ansieht und wie Sie ihn auf moderne Weise umschreiben.

Was sind deprecated Features in Gradle?

Deprecated (veraltete) Funktionen sind die Teile der API, die die Gradle-Entwickler in Zukunft entfernen wollen. Sie wurden aus Gründen der Abwärtskompatibilität beibehalten, aber ihre Verwendung wird nicht mehr empfohlen. Wenn Sie diese Warnung sehen, sagt Gradle im Grunde: "Ihr Projekt wird jetzt noch gebaut, aber nach dem Update auf Version 5.0 nicht mehr".

Meistens liegt das Problem an:

\n
• Veralteten Plugins (z.B. alte Versionen von kotlin-gradle-plugin)
\n
• Impliziten Abhängigkeiten (Verwendung von compile anstelle von implementation)
\n
• Groovy-Skripten, die nicht an das Kotlin DSL angepasst sind
\n
• Direkten Aufrufen von deprecated Methoden in build.gradle
\n

Ansatz 1: Schnelle Lösung — Warnungen unterdrücken

Der einfachste (aber nicht der richtigste) Weg ist, Gradle einfach zu sagen: "Halt den Mund und arbeite". Das ist, als würde man die Check Engine-Leuchte mit Klebeband abkleben. Das Auto fährt, aber die Probleme bleiben.

Fügen Sie in build.gradle.kts (Kotlin DSL) folgenden Block hinzu:

tasks.withType<Wrapper> {\n    gradleVersion = "4.10.3" // Version einfrieren\n}\n\n// Oder Warnung unterdrücken\nallprojects {\n    tasks.withType<AbstractCompile> {\n        options.isDeprecation = false\n    }\n}

Vorteile: schnell, erfordert keine Codeänderungen, der Build läuft durch.

Nachteile: Sie lösen das Problem nicht, sondern verschieben es nur. Beim Wechsel auf Gradle 5.0+ wird das Projekt brechen. Außerdem verpassen Sie wichtige Leistungs- und Sicherheitsverbesserungen.

Wann verwenden: Nur, wenn Sie das Projekt dringend bauen müssen und keine Zeit für Refactoring haben. Planen Sie aber unbedingt eine ordentliche Lösung ein.

Ansatz 2: Migration auf moderne Konfigurationen

Dies ist der "goldene Mittelweg". Sie stopfen nicht nur den Fehler, sondern bringen das Projekt in Ordnung. Lassen Sie uns typische Probleme am Beispiel eines Kotlin-Projekts durchgehen.

Ersetzen von compile durch implementation/api

Die alte Methode zur Deklaration von Abhängigkeiten — compile — wurde bereits in Gradle 3.0 als deprecated markiert. Verwenden Sie stattdessen implementation und api.

Früher (Groovy):

dependencies {\n    compile 'org.jetbrains.kotlin:kotlin-stdlib:1.3.72'\n    compile 'com.squareup.retrofit2:retrofit:2.9.0'\n}

Jetzt (Kotlin DSL):

dependencies {\n    implementation("org.jetbrains.kotlin:kotlin-stdlib:1.9.0")\n    implementation("com.squareup.retrofit2:retrofit:2.9.0")\n}

Der Unterschied ist einfach: implementation verbirgt die Abhängigkeit vor den Konsumenten des Moduls und beschleunigt den Build. api macht sie sichtbar, wie das alte compile.

Aktualisierung des Kotlin-Plugins

Alte Versionen von kotlin-gradle-plugin verwenden oft die deprecated Gradle-API. Überprüfen Sie die aktuelle Version auf kotlinlang.org und aktualisieren Sie