Luego de investigar en varios repositorios y páginas webs al terminar dimos con la solución que te enseñaremos ahora.
Solución:
settings.gradle
los settings.gradle es un script Groovy, al igual que el build.gradle expediente. Sólo uno settings.gradle script se ejecutará en cada compilación (en comparación con múltiples build.gradle scripts en compilaciones de varios proyectos). los settings.gradle script se ejecutará antes que cualquier build.gradle guión e incluso antes de la Project se crean las instancias. Por lo tanto, se evalúa contra un Settings objeto. Con este Settings objeto puede agregar subproyectos a su compilación, modificar los parámetros desde la línea de comando (StartParameter), y acceda a la Gradle objeto para registrar controladores de ciclo de vida. En consecuencia, utilice settings.gradle si su configuración está relacionada con la compilación y no necesariamente relacionada con el proyecto o requiere lógica antes de se incluyen posibles subproyectos.
gradle.properties
los gradle.properties el archivo es un Java simple Properties archivo que solo gana un rol especial al ser incluido automáticamente en el alcance de la Project objeto (como las llamadas ‘propiedades del proyecto’). es un sencillo key-almacén de valor que solo permite string valores (por lo que debe dividir listas o matrices usted mismo). Puedes poner gradle.properties archivos a estas ubicaciones:
- directamente en el directorio del proyecto (para valores relacionados con el proyecto)
- en la casa del usuario
.gradledirectorio (para valores relacionados con el usuario o el entorno)
Un proyecto de varios módulos ha un módulo principal y muchos submódulos. Tiene este diseño:
(root)
+- settings.gradle
+- build.gradle # optional (commonly present)
+- gradle.properties # optional
+-- buildSrc/ # optional
| +- build.gradle
| +-- src/...
+-- my-gradle-stuff/ # optional
| +- utils.gradle # optional
+-- sub-a/
| +- build.gradle
| +- src/
+-- sub-b/
+- build.gradle
+- src/
los submódulos también se pueden ubicar más profundamente en las subcarpetas, pero sin modificar el código en settings.gradle, su nombre incluirá el nombre de dichas carpetas.
configuración.gradle
La función principal de settings.gradle es definir todos los submódulos incluidos y marcar el directorio raíz de un árbol de módulos, por lo que solo puede tener uno settings.gradle archivo en un proyecto de varios módulos.
rootProject.name = 'project-x'
include 'sub-a', 'sub-b'
El archivo de configuración también está escrito en Groovy y la búsqueda de submódulos se puede personalizar.
construir.gradle
Hay uno de esos archivos por módulo, contiene la lógica de compilación para este módulo.
En el build.gradle archivo de la módulo principalpuedes usar allprojects o subprojects para definir la configuración de todos los demás módulos.
En el build.gradle archivo de los submódulos, puede utilizar compile project(':sub-a') hacer que un submódulo dependa del otro.
gradle.properties
Esto es opcional, su objetivo principal es proporcionar opciones de inicio para ejecutar Gradle, por ejemplo.
org.gradle.jvmargs=-Xmx=... -Dfile.encoding=UTF-8 ...
org.gradle.configureondemand=true
Estos valores pueden ser anulados por un archivo USER_HOME/.gradle/gradle.properties, y anulado por los argumentos de la línea de comandos de gradle. También es posible establecer variables de entorno para la compilación en este archivo usando systemProp. como prefix.
Cualquier propiedad en este archivo se puede usar en cualquier build.gradle, por lo que algunos proyectos también incluyen la versión de dependencia o la información de lanzamiento en gradle.propertiespero eso es probablemente un abuso de este archivo.
mis-cosas-de-gradle/utils.gradle
(Cualquier nombre de carpeta o archivo es posible). Puede definir archivos gradle personalizados adicionales para reutilizar definiciones e incluirlos en otros archivos gradle a través de
apply from: "$rootDir/gradle/utils.gradle"
otros lugares para poner esto podrían ser src/gradle o src/build/gradle
buildSrc/…
Esta carpeta es especial, es como un proyecto Gradle separado en sí mismo. Se construye antes de hacer cualquier otra cosa y puede proporcionar una función para usar en cualquier otro archivo gradle. Por motivos técnicos, la compatibilidad con IDE para las referencias a esta carpeta funciona mucho mejor que cualquier otra forma de extraer código común de varios build.gradle archivos a una ubicación separada.
Puede definir una lógica de compilación personalizada compleja en Java, Groovy o Kotlin, en lugar de escribir e implementar un complemento. Esto también es útil para realizar pruebas unitarias de su código de compilación personalizado, ya que puede tener pruebas unitarias. La estructura de la carpeta de origen en buildSrc se puede adaptar como cualquier proyecto java/groovy/kotlin.
Si te gusta este mundo, eres capaz de dejar una crónica acerca de qué le añadirías a esta sección.