Abuild's Groovy backend loads each build item's Abuild.groovy file in a private context such that no two build items' build files can interfere with each other. Although the Abuild.groovy file is a full-fledged Groovy script which could, in principle, run arbitrary Groovy code, the intent is that your Abuild.groovy file do nothing other than set abuild parameters. Abuild parameters are similar to make variables or ant properties. Unlike make variables or ant parameters, they are a construct implemented by abuild's Groovy backend itself rather than being something more fundamental to Groovy. ^[37] Parameters look like ant or Java properties, but unlike ant properties, their values can be modified. Parameter names are typically divided into period-separated components, like abuild.rules or java.dir.dist.

The most common way to set abuild parameters is by assigning to them inside of a parameters block. A parameters block in Abuild.groovy looks something like this:

parameters {
    java.jarName = 'example.jar'
    abuild.rules = ['java', 'groovy']
}

Within a parameters block, things that look like variables are treated as abuild parameters instead. (For a discussion of how this works, see Section 33.9, “Parameter Block Implementation”.) On the left hand side of an assignment, abuild automatically treats the assignment as an assignment to a parameter. On the right hand side, you have to wrap the parameter name in a call to resolve. You can also pass the names of interface variables to resolve. For example, the following would give the parameter item.name the value of the interface variable ABUILD_ITEM_NAME:

parameters {
    item.name = resolve(ABUILD_ITEM_NAME)
}

If the interface variable contains characters that make it invalid as a Groovy identifier, you can quote it, as in the following:

parameters {
    item.parameter = resolve('some-build-item.archive-name')
}

In addition to assigning to parameters, you can append to them by using the << operator, which is the same operator Groovy uses to append to lists. The following three parameter blocks are equivalent:

parameters {
    abuild.rules = ['java', 'groovy']
}
parameters {
    abuild.rules << 'java' << 'groovy'
}
parameters {
    abuild.rules << 'java'
    abuild.rules << 'groovy'
}

It is even possible to delete parameters like this:

parameters {
    delete some.parameter
}

though there should seldom if ever be a need to do this.

Most of the time, working with parameters and parameter blocks is straightforward, but there are some subtleties that may pop up in rare instances. For a full discussion, refer to Section 19.7.3, “Parameters, Interface Variables, and Definitions”.

In a typical Abuild.groovy file, you will be assigning to some rule-specific parameters and to at least one the two parameters provided directly by abuild. The two abuild parameters are abuild.rules and abuild.localRules. The parameter abuild.rules contains a list of rule sets that will be providing code to generate targets from sources. The vast majority of Groovy-based build items will set the abuild.rules parameter. In rare instances, a build item may need to provide additional rules for some one-off purpose. In this case, the parameter abuild.localRules may be set to a list of files, relative to the directory containing the Abuild.groovy file, that implement the local rules. Note that abuild.rules contains the names of rule set implementations while abuild.localRules contains the names of files that contain rule implements. (This makes these parameters consistent with the variables RULES and LOCAL_RULES used by the make backend.) Abuild requires that at least one of abuild.rules and abuild.localRules be set in every Abuild.groovy file.