Gradle 5.0 : comment corriger les fonctionnalités obsolètes et mettre à jour un projet Kotlin

Pourquoi Gradle crie-t-il "Deprecated features" et que faire ?

Avez-vous déjà lancé la compilation d'un projet Kotlin et vu ce message inquiétant : Deprecated Gradle features were used in this build, making it incompatible with Gradle 5.0 ? Si oui, vous n'êtes pas seul. Cette question a rassemblé des milliers de vues sur Stack Overflow, et aujourd'hui nous allons l'analyser en profondeur.

Imaginez : vous écrivez en Kotlin, tout fonctionne, mais Gradle se met soudainement à faire des caprices. Il dit : "Hé, tu utilises de vieilles astuces que je vais supprimer dans la version 5.0 !". C'est un peu comme si votre machine à café préférée vous annonçait que demain, elle n'acceptera plus les vieilles tasses. Désagréable, mais résoluble.

Dans cet article, nous ne montrerons pas seulement comment supprimer l'erreur. Nous comparerons trois approches de résolution : de la solution rapide "rustine" au refactoring professionnel. Vous apprendrez pourquoi Gradle considère votre code comme obsolète et comment le réécrire de manière moderne.

Que sont les fonctionnalités obsolètes (deprecated features) dans Gradle ?

Les fonctions obsolètes (deprecated) sont les parties de l'API que les développeurs de Gradle prévoient de supprimer à l'avenir. Elles sont conservées pour la rétrocompatibilité, mais il n'est plus recommandé de les utiliser. Lorsque vous voyez cet avertissement, Gradle vous dit littéralement : "Ton projet va se compiler maintenant, mais après la mise à jour vers la version 5.0, non".

Le plus souvent, le problème se trouve dans :

\n
• Les plugins obsolètes (par exemple, les anciennes versions de kotlin-gradle-plugin)
\n
• Les dépendances implicites (utilisation de compile au lieu de implementation)
\n
• Les scripts Groovy non adaptés au Kotlin DSL
\n
• Les appels directs à des méthodes obsolètes dans build.gradle
\n

Approche 1 : Solution rapide — suppression des avertissements

Le chemin le plus simple (mais pas le plus correct) est simplement de dire à Gradle : "Tais-toi et travaille". C'est comme mettre du scotch sur le voyant "Check Engine". La voiture roulera, mais les problèmes persisteront.

Ajoutez dans build.gradle.kts (Kotlin DSL) le bloc suivant :

tasks.withType<Wrapper> {\n    gradleVersion = "4.10.3" // gel de la version\n}\n\n// Ou suppression de l'avertissement\nallprojects {\n    tasks.withType<AbstractCompile> {\n        options.isDeprecation = false\n    }\n}

Avantages : rapide, ne nécessite pas de modifications du code, la compilation réussit.

Inconvénients : vous ne résolvez pas le problème, vous le repoussez seulement. Lors du passage à Gradle 5.0+, le projet se cassera. De plus, vous passez à côté d'importantes améliorations de performance et de sécurité.

Quand l'utiliser : uniquement si vous devez compiler le projet en urgence et que vous n'avez pas le temps pour un refactoring. Mais planifiez impérativement une solution normale.

Approche 2 : Migration vers des configurations modernes

C'est le "juste milieu". Vous ne vous contentez pas de masquer l'erreur, vous mettez le projet en ordre. Analysons les problèmes typiques sur l'exemple d'un projet Kotlin.

Remplacement de compile par implementation/api

L'ancienne façon de déclarer les dépendances — compile — était déjà obsolète dans Gradle 3.0. Utilisez plutôt implementation et api.

C'était (Groovy) :

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

C'est devenu (Kotlin DSL) :

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

La différence est simple : implementation cache la dépendance aux consommateurs du module, accélérant la compilation. api la rend visible, comme l'ancien compile.

Mise à jour du plugin Kotlin

Les anciennes versions de kotlin-gradle-plugin utilisent souvent l'API obsolète de Gradle. Vérifiez la version actuelle sur kotlinlang.org et mettez à