Chapter 12[ 339 ]The example code for this chapter can be found in the TicTacToe directory of the
source pack. There are two subdirectories in here, www which contains the HTML5
UI which we will discuss later, and server which contains the game server and DSL
sources. The server directory contains a Gradle build script build.gradle.
Underneath server there is another subdirectory ast, this is where the sources for the
AST transformation lives. It also contains a build.gradle, which is configured to
build a JAR distribution of the game engine AST transformation:
apply plugin: 'groovy'repositories {
mavenCentral()
}dependencies {
compile "org.codehaus.groovy:groovy-all:2.4.3"
testCompile "org.spockframework:spock-core:0.7-groovy-2.0"
}This will build a JAR file for the AST in server/ast/build/libs/ast.jar.
The server build.gradle consumes this JAR as a project dependency with the
following entry in its dependencies:
dependencies {
compile project(':ast')
}With this build structure in place, Gradle will ensure that the JAR containing the AST
is built first and made available at compile time for the server. The tests for the server
and the AST can be run via Gradle on the command line:
$gradle clean test
Debugging
Debugging an AST transform can be difficult at the best of times. Attaching a
debugger via Eclipse or IntelliJ is possible. However, in the early stages of DSL
development, I find that the simplest solution is just to put some logging into your
AST transform code. You can dump what the DSL is doing at any point in time.
There is one aspect of DSL development that is particularly difficult to debug. That
is when your transform has finished and produced an end set of transformed classes,
but now these classes don't behave as expected. You don't have the code for these
classes to debug them because you generated them dynamically in the transform.