¿Cuándo usar gradle.properties frente a settings.gradle?

Una compilación de Gradle tiene tres archivos

• build.gradle que define los scripts de configuración de compilación
• gradle.properties
• settings.gradle

Preguntas

• ¿Cuáles son las diferencias entre settings.gradle& gradle.properties?
• ¿Cuándo debe colocarse una configuración settings.gradlevs. gradle.properties?

settings.gradle

El settings.gradlearchivo es un script Groovy, al igual que el build.gradlearchivo. Solo settings.gradlese ejecutará un script en cada compilación (en comparación con varios build.gradlescripts en compilaciones multiproyecto). El settings.gradlescript se ejecutará antes que cualquier build.gradlescript e incluso antes de que Projectse creen las instancias. Por lo tanto, se evalúa frente a un Settingsobjeto. Con este Settingsobjeto, puede agregar subproyectos a su compilación, modificar los parámetros desde la línea de comando ( StartParameter) y acceder al Gradleobjeto para registrar controladores de ciclo de vida. Como consecuencia, utilícelo settings.gradlesi su configuración está relacionada con la compilación y no necesariamente relacionada con el proyecto o si requiere lógica antes de incluir posibles subproyectos.

gradle.properties

El gradle.propertiesarchivo es un Propertiesarchivo Java simple que solo adquiere un rol especial al ser incluido automáticamente en el alcance del Projectobjeto (como las llamadas 'propiedades del proyecto'). Es un almacén de clave-valor simple que solo permite valores de cadena (por lo que debe dividir listas o matrices usted mismo). Puede colocar gradle.propertiesarchivos en estas ubicaciones:

• directamente en el directorio del proyecto (para valores relacionados con el proyecto)
• en el .gradledirectorio de inicio del usuario (para valores relacionados con el usuario o el entorno)

Un proyecto de varios módulos tiene 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.

settings.gradle

La función principal de settings.gradle es definir todos los submódulos incluidos y marcar la raíz del directorio de un árbol de módulos, por lo que solo puede tener un settings.gradlearchivo 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.

build.gradle

Hay uno de esos archivos por módulo, contiene la lógica de compilación para este módulo.

En el build.gradlearchivo del módulo principal , puede usar allprojects {}o subprojects {}para definir configuraciones para todos los demás módulos.

En el build.gradlearchivo de los submódulos, puede usar compile project(':sub-a')para hacer que un submódulo dependa del otro.

gradle.properties

Esto es opcional, su propósito principal es proporcionar opciones de inicio para usar 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.propertiesy anulados 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 prefijo.

Cualquier propiedad de 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 gradle.properties, pero es probable que se abuse de este archivo.

my-gradle-stuff / utils.gradle

(Es posible cualquier nombre de carpeta o archivo). Puede definir archivos gradle personalizados adicionales para reutilizar las definiciones e incluirlas en otros archivos gradle a través de

apply from: "$rootDir/gradle/utils.gradle"

otros lugares para poner esto podrían ser src/gradleosrc/build/gradle

buildSrc / ...

Esta carpeta es especial, es como un proyecto de Gradle separado en sí mismo. Se crea antes de hacer cualquier otra cosa y puede proporcionar una función para usar en cualquier otro archivo gradle. Por razones técnicas, el soporte de IDE para referencias a esta carpeta funciona mucho mejor que cualquier otra forma de extraer código común de varios build.gradlearchivos 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 buildSrcse puede adaptar como para cualquier proyecto java / groovy / kotlin.