Gestión de dependencias en proyectos de varios módulos en granizo

Entrada

El artículo está escrito teniendo en cuenta los proyectos nativos de Android, pero, dado que el gradle es un sistema de ensamblaje universal, en principio, será adecuado para otros proyectos que el gradle puede recopilar. La idea no es mía, la tomé del proyecto github de Jake Wharton SdkSearch , un conjunto de programas para buscar en la documentación de Android SDK.

El problema

Una aplicación moderna es casi imposible (poco práctica) de escribir sin usar bibliotecas. Con la llegada de las dependencias, surge la tarea de administrar versiones. Quizás para una aplicación de Android de un solo módulo de la mano media esto no sea un problema, luego, en proyectos más grandes con reutilización de código, el problema es relevante. Especialmente en el control de versiones de las bibliotecas de Androidx de soporte para las cuales el control de versiones es simplemente más allá de lo razonable, solo mire las versiones de AndroidX

Solución

Con tantas dependencias, es muy importante que todos los módulos dependan de una versión de la biblioteca, de lo contrario, las sorpresas en tiempo de ejecución saldrán en el lugar más inesperado.
Gradle utiliza groovy como lenguaje de script, lo que, junto con la escritura dinámica, brinda una oportunidad conveniente para optimizar la administración de dependencias.

En el grad DSL, puede agregar propiedades al proyecto utilizando el objeto ext ExtraPropertiesExtension . Además, dentro de la secuencia de comandos del módulo, puede acceder a la secuencia de comandos del proyecto (módulo raíz), que le permite declarar todas las versiones de las dependencias en la secuencia de comandos raíz, y ya puede consultarlas desde cualquier módulo dentro.

Por ejemplo, deje que nuestra aplicación de Android use las dependencias: kotlin, kotlin stdlib, kotlin junit, facebook sdk, androidx, google material

Root 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}" } } 

Un par de puntos:
Si varias dependencias tienen una versión, por ejemplo, partes de un SDK grande, la versión se agrega a la propiedad de versiones, como por ejemplo con las versiones de Kotlin y Facebook. Si la dependencia tiene la forma de una sola línea, como material de google, entonces no es práctico hacer una versión. Las versiones de las bibliotecas de Androidx tampoco necesitan ser eliminadas, porque Google se negó a alinear versiones entre sí para acelerar las versiones de bibliotecas individuales.

Como resultado de esta definición, en todos los módulos secundarios, la declaración de dependencias se convierte en una jerarquía concisa libre de control de versiones, porque ahora todos los módulos dependen de las mismas versiones de biblioteca.

ejemplo de la sección de dependencias del módulo en 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 } 

Lo que sucedió: las versiones de biblioteca de los módulos desaparecieron, apareció una jerarquía de bibliotecas
También vale la pena señalar que el módulo no tiene que depender de todas las bibliotecas descritas en el script raíz, sino solo de las que son necesarias.

Como mencioné anteriormente, un borrador de trabajo que utiliza dicho esquema está aquí .