Validate properties

(Thor Kummer) #1

I see there is an issue to validate properties (GRADLE-2684) and warn of an undeclared property, which I think is a good idea. It would also be nice to be able to

(1) Declare the type of the property and have it coerced into it. This could make the code cleaner in many cases.


declare name: ‘wsdlUrl’, type: URL

def wsdl = wsdlUrl.text


declare name: ‘isJsp’, type: boolean

if(isJsp) {


instead of

if(isJasp == ‘true’)

or something similar


declare name: servicesDir, type ExistingDir

Where ExistingDir throws an exception if servicesDir doesn’t exist or isn’t ad Dir. Saves a few lines of code.

(2) Declare if the property must be present, even on a per task bases. The properties could be delared in the configuration of the root project and then be ‘required’ in the tasks where they actually are required.


task generateCode << {

requires ‘servicesDir’, ‘wsdl’


task compileJsp << {

requires ‘isJsp’


task deploy << {

requires ‘jbHost’, ‘deployDir’


(3) Define a constraint on the property using the isCase() methods.


declare name: ‘targetHost’, constraint: ~/test.*/


declare name: numHosts, type: int, constraint: 1…10


declare name: releaseDate, type: IsoDate, constraint: { it - 1 < new Date() }


declare name: wsdlDir, type: File, constraint: { it.exists() && }

Where IsoDate is Date that lets itself be constructed with an ISO date-string.

(4) Be able to declare a default value.


declare name: numIterations, type: int, contstraints: { it > 0 }, value: 1

(5) Fails (optionally) if it meets an undeclared property, rather than just warn.

I have a small groovy class that implements this, which I would be happy to donate (if my boss doesn’t object:)

(Peter Niederwieser) #2

Some of this already exists in one way or another (extra properties, validated task inputs, Groovy coercion of typed properties). We do plan to offer more on the coercion/validation side, but likely only for typed models (i.e. tasks and extensions implemented as classes and leveraging static typing).

If you are interested in getting involved in one of these efforts, let us know. To get up to speed with existing ideas, I recommend to read through ‘design-docs/implicit-file-type-coercion’ in the GitHub repo.