java - example - ¿Cuándo usar gradle.properties vs. settings.gradle?
gradle vs maven (2)
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)
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
ygradle.properties
? -
¿Cuándo se debe poner una configuración en
settings.gradle
vs.gradle.properties
?
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.