Gestion des dépendances dans un projet multi-modules sur la grêle

Entrée

L'article est écrit en tenant compte des projets Android natifs, mais comme le gradle est un système d'assemblage universel, il conviendra en principe à d'autres projets que le gradle peut collecter. L'idée n'est pas la mienne, je l'ai obtenue du projet github de Jake Wharton SdkSearch - un ensemble de programmes pour rechercher la documentation pour Android SDK.

Le problème

Une application moderne est presque impossible (peu pratique) à écrire sans utiliser de bibliothèques. Avec l'avènement des dépendances, la tâche de gestion des versions se pose. Peut-être que pour une application Android à module unique de la main du milieu, ce n'est pas un problème, alors dans les grands projets avec réutilisation de code, le problème est pertinent. Surtout dans le contrôle de version des bibliothèques de support androidx pour lesquelles le contrôle de version est simplement au-delà du raisonnable, il suffit de regarder les versions d'AndroidX

Solution

Avec autant de dépendances, il est très important que tous les modules dépendent d'une seule version de la bibliothèque, sinon les surprises lors de l'exécution apparaîtront à l'endroit le plus inattendu.
Gradle utilise groovy comme langage de script, qui, couplé à une frappe dynamique, offre une opportunité pratique pour rationaliser la gestion des dépendances.

Dans le grad DSL, vous pouvez ajouter des propriétés au projet à l'aide de l' objet ext ExtraPropertiesExtension . De plus, à l'intérieur du script de module, vous pouvez accéder au script de projet (module racine), qui vous permet de déclarer toutes les versions des dépendances dans le script racine, et vous pouvez déjà vous y référer à partir de n'importe quel module à l'intérieur.

Par exemple, laissez notre application Android utiliser les dépendances: kotlin, kotlin stdlib, kotlin junit, facebook sdk, androidx, google material

Racine build.gradle:

buildscript { ext { versions = [ 'kotlin': '1.3.50', 'fb': '4.40.0' ] deps = [ 'kotlin': [ 'stdlib': [ 'jdk': "org.jetbrains.kotlin:kotlin-stdlib-jdk7:${versions.kotlin}" ], 'test': [ 'common': "org.jetbrains.kotlin:kotlin-test-common:${versions.kotlin}", 'annotations': "org.jetbrains.kotlin:kotlin-test-annotations-common:${versions.kotlin}", 'jdk': "org.jetbrains.kotlin:kotlin-test-junit:${versions.kotlin}" ] ], 'androidx' : [ 'annotation': "androidx.annotation:annotation:1.1.0", 'appCompat': 'androidx.appcompat:appcompat:1.1.0', 'constraintLayout': 'androidx.constraintlayout:constraintlayout:1.1.3', 'ktx': 'androidx.core:core-ktx:1.1.0', 'dynamicAnimation': 'androidx.dynamicanimation:dynamicanimation:1.0.0', 'gridLayout': 'androidx.gridlayout:gridlayout:1.0.0', 'localBroadcastManager': 'androidx.localbroadcastmanager:localbroadcastmanager:1.0.0', 'multidex': 'androidx.multidex:multidex:2.0.1', 'recyclerView': 'androidx.recyclerview:recyclerview:1.1.0-beta04' ], 'material': 'com.google.android.material:material:1.0.0', 'fb': [ 'core': "com.facebook.android:facebook-core:${versions.fb}", 'login': "com.facebook.android:facebook-login:${versions.fb}", 'share': "com.facebook.android:facebook-share:${versions.fb}" ] ] repositories { google() jcenter() } dependencies { classpath 'com.android.tools.build:gradle:3.6.0-alpha11' classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:${versions.kotlin}" } } 

Quelques points:
Si plusieurs dépendances ont une version, par exemple, des parties d'un grand SDK, alors la version est ajoutée à la propriété versions, comme par exemple avec les versions de Kotlin et Facebook. Si la dépendance se présente sous la forme d'une seule ligne, comme du matériel google, il n'est pas pratique de créer une version. Il n'est pas non plus nécessaire de supprimer les versions des bibliothèques androidx, car Google a refusé d'aligner les versions les unes avec les autres pour accélérer les sorties de bibliothèques individuelles.

À la suite de cette définition, dans tous les modules enfants, la déclaration de dépendances devient une hiérarchie concise sans versioning, car maintenant, tous les modules dépendent des mêmes versions de bibliothèque.

exemple de la section des dépendances de module dans build.gradle

 dependencies { implementation deps.kotlin.stdlib.jdk implementation deps.androidx.appCompat implementation deps.androidx.browser implementation deps.androidx.cardView implementation deps.androidx.constraintLayout implementation deps.androidx.ktx implementation deps.androidx.multidex implementation deps.androidx.recyclerView implementation deps.material implementation deps.fb.core implementation deps.fb.login implementation deps.fb.share testImplementation deps.kotlin.test.jdk } 

Ce qui s'est passé - les versions de bibliothèque des modules ont disparu, une hiérarchie de bibliothèques est apparue
Il convient également de noter que le module ne doit pas dépendre de toutes les bibliothèques décrites dans le script racine, mais uniquement de celles qui sont nécessaires.

Comme je l'ai mentionné ci-dessus, un projet de travail utilisant un tel schéma est ici .