java - example - ¿Cuándo usar gradle.properties vs. settings.gradle?

gradle vs maven

Question

Una compilación 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 y gradle.properties ?
• ¿Cuándo se debe poner una configuración en settings.gradle vs. gradle.properties ?

Answer 1

settings.gradle

El archivo settings.gradle es un script Groovy, al igual que el archivo build.gradle . Solo se ejecutará un script settings.gradle en cada compilación (en comparación con varios scripts build.gradle en compilaciones multiproyecto). El script settings.gradle se ejecutará antes de cualquier script build.gradle e incluso antes de que se creen las instancias del Project . Por lo tanto, se evalúa contra un objeto de Settings . Con este objeto Settings , puede agregar subproyectos a su compilación, modificar los parámetros desde la línea de comando ( StartParameter ) y acceder al objeto Gradle para registrar controladores de ciclo de vida. Como consecuencia, use settings.gradle si su configuración está relacionada con la compilación y no necesariamente con el proyecto o requiere lógica antes de incluir posibles subproyectos.

gradle.properties

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

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

Answer 2

Un proyecto de varios módulos tiene un módulo principal y muchos submódulos. Tiene este diseño:

(root)
+- settings.gradle
+- build.gradle
+- gradle.properties # optional
+-- buildSrc/ # optional
| +- build.gradle # optional
| +-- src/ # optional
| +-- test/ # optional
+-- gradle/ # 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 archivo settings.gradle 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 archivo build.gradle del módulo principal , puede usar todos los allprojects {} o subprojects {} para definir la configuración de todos los demás módulos.

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

gradle.properties

Esto es opcional, su objetivo 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.properties , y anulados por argumentos de línea de comando gradle. También es posible establecer variables de entorno para la compilación en este archivo usando systemProp. como prefijo

Cualquier propiedad en este archivo se puede usar en cualquier build.gradle, por lo que algunos proyectos también ponen información de versión o versión de dependencia en gradle.properties , pero es probable que sea un abuso de este archivo.

gradle / utils.gradle

(Es posible cualquier nombre de carpeta o archivo). 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"

buildSrc / ...

Esta carpeta es especial, es como un proyecto Gradle separado en sí mismo. Está construido antes de hacer cualquier otra cosa, y puede proporcionar funciones 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 múltiples archivos build.gradle 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 realizar pruebas unitarias.