properties - Propiedades adicionales de Gradle no visibles en una tarea personalizada definida en un subproyecto

task extra

Question

Estoy tratando de reutilizar la lógica común entre múltiples tareas de Gradle, similar a lo que se sugirió en esta respuesta , pero tengo problemas con las propiedades adicionales del proyecto que no son visibles.

Hervido, aquí está el problema. Digamos que tengo un script de compilación de Gradle raíz, build.gradle que establece una propiedad de proyecto adicional,

project.ext.myProp = ''myValue''

Tengo un subproyecto definido en settings.gradle ,

include ''subproject''

y el subproyecto define y usa una tarea personalizada que hace referencia a esa propiedad adicional del proyecto,

class CustomTask extends DefaultTask {
CustomTask() {
doFirst {
println project.ext.myProp
}
}
}
task custom(type: CustomTask) {
println ''custom task''
}

Ejecutar esto me da esto:

FAILURE: Build failed with an exception.
...
* Exception is:
org.gradle.api.GradleScriptException: A problem occurred evaluating project '':subproject''.
...
Caused by: org.gradle.api.tasks.TaskInstantiationException: Could not create task of type ''CustomTask''.
...
Caused by: groovy.lang.MissingPropertyException: cannot get property ''myProp'' on extra properties extension as it does not exist
...
BUILD FAILED

Tenga en cuenta que esto parece funcionar si:

• La tarea personalizada se define en el proyecto raíz junto con la propiedad adicional
• Si usa propiedades dinámicas en lugar de propiedades adicionales, pero esas están en desuso

Answer 1

La sintaxis recomendada para leer una propiedad adicional llamada foo en un script de compilación es foo o project.foo (en lugar de ext.foo ), que también buscará las propiedades (extra) de los proyectos principales. EDITAR: En una clase de tarea, puede usar project.foo .

Es importante tener en cuenta que las propiedades adicionales solo están destinadas a scripts ad-hoc en scripts de compilación; Las clases de tareas y los complementos no deben usarlos. Una clase de tarea no debería llegar al modelo de objetos de Gradle; en su lugar, debe declarar las propiedades (y, si es necesario, los métodos) que permiten que los scripts y / o complementos de compilación le proporcionen toda la información que necesita. Esto hace que sea más fácil de entender, reutilizar y documentar la clase de tarea, y permite declarar entradas y salidas a través de las @Input... y @Output...

PD: en lugar de llamar a doFirst en un constructor, una clase de tarea generalmente tiene un método anotado con @TaskAction .