30.3. Guidelines for Groovy Target Authors

All Groovy files loaded by abuild are Groovy scripts. This
gives you plenty of rope with which you can hang yourself. When
creating rules or other Groovy code for use with abuild keep in
mind following guidelines:

If your code does anything more elaborate than adding
stand-alone closures, consider having your script explicitly
define a class and then instantiate it. This provides a
“fence” to protect us against certain types of
errors, such as mistyping a field name and ending up adding
something to the binding instead. All built-in Groovy rules
provided by abuild follow this convention.

When writing custom rules or defining additional targets,
allow all defaults to be overridable through parameter
settings. This helps to avoid locking the user into a set of
conventions. Abuild's Groovy backend's
runActions method provides an easy
framework that enables your rules to offer the same layers of
customization that are provided by abuild's own rules. For
an example of using this construct, see Section 22.3, “Code Generator Example for Groovy”.

When developing support for a new test framework, you only
have to add new closures for the test-only
target. Abuild automatically calls the
test-only from both test
and check. This is actually different in
the make backend, which requires adding code to all three
test-related targets. The reason we don't have to do this in
Groovy is that our target framework allows to explicitly call
one target from another in a dependency-aware fashion.

Instead of adding closures to test-only,
you may instead decide to create your own custom target, make
it a dependency of test-only, and add your
closures to your custom target. This is what both QTest and
JUnit support do. The advantage of this approach is that it
makes it possible for you invoke a particular collection of
tests explicitly and, for build items that use more than one
test framework, prevents later tests from being skipped if
earlier ones fail.

The best way to learn about what is offered by abuild's Groovy
backend is to study existing rules from the
rules directory in your abuild
distribution. You can find a complete copy of the
java rules in Appendix J, The java.groovy and groovy.groovy Files. If you're really adventurous,
you can read the source to the Groovy backend itself in
abuild's source distribution.