Ant transforms using Groovy template scriptdef

April 9, 2012

Ant provides powerful transformation capability. For example, the copy task can include filters that replace tokens in the text. There is also the XSLT task to perform more complex XML based transforms.

Sometimes you may need more dynamic or procedural transforms for non-xml based templates. While this can be done in Ant, they should not be; Ant should really only be used in a declarative manner. One can do this outside of Ant using custom solutions or use the various templating frameworks, such as Velocity and Freemarker, which provide Ant plugins.

Another alternative is the Groovy language which has always provided text processing in the form of GStrings and templates. These are used in various solutions such as Groovlets and Groovy Server Pages. Below I show how Groovy templates can be easily used in Ant.

listing 1 shows a meeting agenda text template with a list of topics. Note that it has a GString interpolated string using “$” character. It also, analogous to Java Server Pages, uses a scriptlet with <% and %> to execute code. Yes I know, scriptlets are evil.

List 1, template1.txt, a template:

Hello ${name}!
Agenda is:
%>- $it 
<% }	

In listing 2 below, an Ant script invokes the “template” task to transform the template in listing 1.

Listing 2, build.xml, use template task:

<project default="init">
<import file="tasks.xml"/>
<target name="init" 
	<property name="name"    
	<property name="subject" 

Listing 3 shows an example run.

Listing 3, example use:

Saving result to temp.txt
     [echo] Hello world!
     [echo]     Agenda is:
     [echo]     - beans
     [echo]     - GStrings
     [echo]     - templates


Listing 4 is the implementation. It is a simple scriptdef using Groovy as the script language. The Groovy code is inline but could have been in external file using the “src” attribute of the scriptdef declaration.

Listing 4, tasks.xml, the scriptdef implementation:

<!-- config stuff not shown -->

Render a Groovy template using properties to create the binding 
<scriptdef name="template" 
  <attribute name="src"/>   <!--  required -->
  <attribute name="dest"/>  <!--  optional -->
  <attribute name="property"/> <!--  optional -->
  <attribute name="failOnError"/> <!--  optional, true -->
  <element name="property" type="property"/> <!--  required -->
def SRC= 'src';
def PROPERTY = 'property'
def DEST = 'dest'
def FAILONERROR = 'failonerror'
	// convert element properties to map
	def map = [:]
	// render the template
	String result = new groovy.text.GStringTemplateEngine()
	  .createTemplate(new File(attributes.get(SRC))
	def prop = attributes.get(PROPERTY)
	if(prop){ // save to property?
		project.setNewProperty(prop, result)
	def dest = attributes.get(DEST)
	if(dest){ // write to file?
		project.log("Saving to $dest",project.MSG_INFO)
		new File(dest).write(result)
}catch(Exception ex){
	def f = attributes.get(FAILONERROR)
	def failOnError = f ? f : true;

	if(failOnError == 'true'){
		throw ex;
</scriptdef>  <!-- end name="template" -->


Shown was an example of using Groovy templates in an Ant task. A simple scriptdef was created to allow reuse in Ant scripts.

Kind of begs the question, since scriptlets have a bad rep, should there instead be a way of using taglibs in the templates. I think Grails implemented Groovy taglibs.


Groovy script to bootstrap a Gradle Project

March 8, 2012

I took Ted Naleid’s “Quick Shell Function to Bootstrap a Gradle Groovy Project” example code and converted it to a Groovy script.

Listing 1.

// NewGradle.groovy
// Author: Josef Betancourt
// Based on T. Naleid's shell script 

println "Creating files for new Gradle project ..."

new File(".gitignore").withPrintWriter{ w ->

new File("build.gradle") << ="""\
apply plugin: 'groovy'
apply plugin: 'idea'
apply plugin: 'eclipse'
repositories {
dependencies {
    groovy 'org.codehaus.groovy:groovy:1.8.6'
    compile 'org.apache.ivy:ivy:2.2.0'
task createSourceDirs(description : 
   'Create empty source directories for all defined sourceSets') 
   << {
        sourceSets*.allSource.srcDirs.flatten().each { 
            File sourceDirectory ->        
            if (!sourceDirectory.exists()) {
                println "Making \$sourceDirectory"
idea {
    project {
        jdkName = '1.6'

""" // end content

"cmd /c gradle createSourceDirs".execute()

"cmd /c git init".execute()

	sleep 5000 // allow time for all files to be created
	new File(".").eachFile{
		println it

Not expert Groovy, but was easy to do. The bulk of it is the creation of a “here” doc using Groovy’s triple quote string. I didn’t duplicate the last line of Naleid’s script: “ls -a1 && find src # list all created assets”.

This script is not fully cross-platform. The invocation of shell commands at the end are in the Windows format. Left as an exercise to reader is the use of inline AntBuilder to reuse Ant’s exec task. :-)

2012-03-09: Tweaked the source. Removed use of two temp variables.
2012-03-09: Added the Eclipse plugin. Now after creating the Gradle project executing eclipse will create the eclipse project: gradle eclipse
Or instead generate the Idea project: gradle idea.

Further Reading

  1. Copy of this post
  2. Groovy (Programming language)
  3. Groovy
  4. Gradle
  5. Quick Shell Function to Bootstrap a Gradle Groovy Project
  6. Strings and GString
  7. Groovy JDK extensions
  8. Executing External Processes
  9. Using Gradle to Bootstrap your Legacy Ant Builds

Off Topic

How to fail an Ant Groovy Scriptdef task

February 18, 2012

While you can certainly just throw an exception in a scriptdef to stop an Ant script that is using a scriptdef, perhaps it is best to use Ant’s Exit task. This allows Ant to do whatever it has to do as it handles the resulting BuildException.

The exit task is used in an Ant script as “fail”. To use ‘fail’ in a scriptdef you just use the predefined ‘self’ variable that references the scriptdef instance. This is illustrated in listing 1 below.

An alternative to the scriptdef ant task is to use the ‘groovy’ task that comes with the Groovy environment. This is perhaps the simplest approach when you don’t need the full structure that the scriptdef task makes available to a script. The scriptdef task allows one to pass in Ant XML elements and attributes.

Listing 1

<project name="example" default="demo">

  <!-- reference the groovy libs -->
  <path id= "libs" >
    <fileset dir= "../lib">
      <include name="groovy/groovy-all-1.8.6.jar" />

  <!-- An inline scriptdef that throws an exception -->
  <scriptdef name="solveProblem" 
        language="Groovy" classpathref="libs">"intentionally failed")	 


  <!-- a call of the scriptdef -->
  <target name="demo">

A run …

>ant -f fail.xml
Buildfile: fail.xml


fail.xml:15: intentionally failed

Total time: 1 second

Further reading

Using Commons SCXML with Groovy

October 16, 2011

The Watch example is rewritten using Groovy. The actual state machine document is created using Groovy‘s MarkupBuilder.

More then a decade ago I used a state machine approach to develop a web application framework. It worked, which surprised me most of all, lol! Since then I’ve wondered why there is no generic reuseable facility to use this approach.

SCXML is “…a general-purpose event-based state machine language that combines concepts from CCXML and Harel State Tables”. It would seem to fit the bill.

Many applications would probably benefit from having the control flow managed by some kind of flow engine. Sometimes we wind up with the internal object’s implicit FSM mixed into the application FSM in tangles of confusion and brittleness.

Modern software engineering is just the use of more ingenious complex frameworks for obfuscating the finite state machines really being created. This is especially true in the Java world, where there is a tendency toward frameitis.

Listing one below is a version of the Watch example presented on the Commons SCXML site. Instead of subclassing the AbstractStateMachine, this version uses the SCXMLExecutor and extends SCXMLListener. The listener allows the engine to invoke methods on the demo class by setting itself as the invoker: executor.registerInvokerClass(“watch”,getClass());

Note: The Groovy Grab will not work in Eclipse. I just put the required jars in the build path. The grab will work in the command line.

Listing one

// file: ScxmlDemo.groovy
import groovy.xml.*
import groovy.grape.*

import java.awt.datatransfer.Transferable;
import java.lang.reflect.Method
import org.apache.commons.scxml.*
import org.apache.commons.scxml.env.*
import org.apache.commons.scxml.invoke.*
import org.apache.commons.scxml.model.*
import org.apache.commons.scxml.env.jsp.*


 * Demo of 
 * "...State Chart XML (SCXML), which is a general-purpose 
 * event-based state machine language that combines 
 * concepts from CCXML and Harel State Tables."
 * Invocation:
 *   groovy src\ScxmlDemo.groovy
 * @author jbetancourt
public class ScxmlDemo implements SCXMLListener {
	SCXMLExecutor executor
	def namespace = ""
	Map methods = [:]
	enum Trans{
		String name;
		public Trans(String s){
			name = s

	/**   */
	public ScxmlDemo(){
				getDeclaredMethod(it, new Class[0]))

	/** Instead of writing XML, we use a DSL builder to create it */
	def createScxmlDoc(){
		def writer = new StringWriter()
		def builder = new MarkupBuilder(writer)


		new File("sm.xml").setText(writer.toString())

	/**   */
	public void execute(){
		def eh = new
		SCXML model = SCXMLParser.parse(
				new File("sm.xml").toURI().toURL(), eh)

		executor = new SCXMLExecutor()
		executor.setRootContext(new SimpleContext())
		executor.setEvaluator(new ELEvaluator())
		executor.setErrorReporter(new SimpleErrorReporter())
		executor.setEventdispatcher(new SimpleDispatcher())
		executor.addListener(model, this)


		def status = executor.getCurrentStatus().
		status.each{ println "Now state is: ${}" }

	/**  */
	public void fireEvent(name){
		def evts = [
			new TriggerEvent(name,
			TriggerEvent.SIGNAL_EVENT, null)

		executor.triggerEvents(evts as TriggerEvent[])

	/**  */
	def invoke(id){
		try {
			def name = 'do' + id.substring(0,1).
				toUpperCase() + id.substring(1)
			def method = methods[name]
			method.invoke(this, new Object[0]);
			return true
		}catch(Exception ex){
		return false

	/**  */
	public void onEntry(
	final TransitionTarget entered) {

	 * @param from The &quot;source&quot; transition target.
	 * @param to The &quot;destination&quot; transition target.
	 * @param transition The transition being followed.
	public void onTransition(
	   final TransitionTarget from,
	   final TransitionTarget to,
	   final Transition transition) {
		// nothing to do

	 * @param exited The transition target being exited.
	public void onExit(final TransitionTarget exited) {
		// nothing to do

	// the activities
	def show(s){println "I'm '$s' ..."}
	public void doReset() {show('reset')}
	public void doRunning() {show('running')}
	public void doPaused() {show('paused')}
	public void doStopped() {show('stopped')}

	public static main(args){
		def main = new ScxmlDemo()

Example run:

groovy src\ScxmlDemo.groovy
I'm 'reset' ...
I'm 'running' ...
Now state is: running

Presented was an example of implementing the Watch example application using the Groovy programming library. The Groovy MarkupBuilder gives a “better” language then XML for creating the state machine document.

SCXML can be the basis of a State-Oriented Programming approach.


Further Reading


My Funny Valentine / Bill Evans & Jim Hall

Current Git repo branch name using Groovy

October 14, 2011

As some light research I was looking at how to determine a Git repository’s current branch name in a Groovy script.

In the Git CLI this would be shown with:

C:\temp\gitSdWf\project>git branch
* master

The current branch is shown with a leading asterisk.

Invoke Git
One method is to just invoke the Git executable:

gitExe = "\\servers\\Git\\bin\\git.exe"
currentBranch = ''

matcher = ~/\* (.*)\s/

process = "${gitExe} branch".execute(){ 
     line -> println line
     m = line =~ /\*\s+(.*)\s?/
          currentBranch = m[0][1] 

println "current: '$currentBranch'"

Use JGit library
Another is to use a Java based Git library like JGit:


import org.eclipse.jgit.*
import org.eclipse.jgit.lib.*
import org.eclipse.jgit.util.*

directory = new File(args[0])

Repository repository =

This would be run as:
groovy testGit.groovy \temp\gitSdWf\depot\project.git

One problem with the JGit approach is that, afaik, this won’t work if the repo is represented by a ‘pointer’ file, i.e., created with the –separate-git-dir option. Also, unlike the Git branch command, you must open the target git repo at it’s root level, not a nested subdirectory of the repo.

— Windows 7 64bit Professional
— git version 1.7.6.msysgit.0
— Groovy Version: 1.8.2 JVM: 1.6.0_25


Oregon – Yet To Be (live)

Archive files using Ant from Groovy

September 12, 2011

In Ant The zip task takes a fileset but only creates one archive. How do you zip files into individual archives?

Use case
One use case for this is log files. Sooner rather then later, every system must deal with the growth of log files. One of the best utilities for handling this is logrotate. This is available on *nix systems. There are probably native versions that do similar tasks in Windows, but I did not locate any ‘free as in beer’ ones.

Since I’m working with Ant, on Windoze, and can’t install cygwin or other system, will use Groovy to get around Ant limitations. This will not be an attempt to recreate logrotate, of course.

As in a previous post, we can use the Groovy AntBuilder and iterate a fileset to repeatably call an Ant task. In this case we’ll be invoking the zip task. Note that the same approach could be used to create a scriptdef to do this directly in an Ant build script. This would be more usable since we could declaratively define the fileset, etc.


First the configuration. In listing 1, we use a JSON configuration file. No reason, I’m just tired of Property files.

Listing 1, JSON configuration file

{ "about":

In listing 2, the main entry point calls the config loader and then the ‘archiveLogs’ method.

The fileset created with the AntBuilder uses an Ant ‘date’ selector to find the files that are x amount of days old. Then the resulting fileset is scanned in a loop, invoking the zip task as we go and then deleting the just zipped file. It is assumed here that the target file name has descriptive information, like a date. And, we are not adding a “rotate” counter to the name for future logrotate like behavior.

Listing 2, Groovy archive source

package ant

import java.text.*
import groovy.json.JsonSlurper

 * @author jbetancourt
class ArchiveLogs {
	def format = "yyMMdd'T'kkmm"
	def df = new SimpleDateFormat(format)

	/** entry point */
	static main(args) {
		def als = new ArchiveLogs()	
		def p = (
		  (args) ?
		  args[0] : "test/conf/archivelogs.json")
		def map = als.loadConfiguration(p)

	/**  */
	def archiveLogs(conf) {
		def base = conf.base
		def targetDateString = df.format(
			(new Date() - Integer.parseInt(conf.days))
		def ant = new AntBuilder()		
		def ref = ant.project.getReference(
		ref.each{ fileResource ->
			File file = fileResource.getFile()
			def name = file.getName()
	/** load json file */
	def loadConfiguration(String path){
		def slurper = new JsonSlurper()
		def obj = slurper.parse(
			 new File(path).newReader())
		if(obj.config.debug == 'true'){
				println it
		return obj.config

This is, of course, a simplistic approach. For example, what if the file is being used when we attempt to delete it? Or we fail to zip the file, but continue to delete it? And, this source, being an example, does not have any error handling.

The ant-contribs project has looping support, foreach. Directly using the Java util packages for archiving, such as Or, the libraries found in, for example, the Apache commons project.

Further Reading

“cafe”, egberto gismonti

Groovy Scriptdef to detect properties with trailing spaces

September 2, 2011

One potential source of errors in a project is the presence of undesired terminating spaces on properties loaded by java.util.Properties. Since property files are also used to deploy or configure applications, it is possible for these sources of errors to disrupt deployed services.

There are of course many options to prevent this from happening, such as:
1. Property file or general editors that can detect or show “spaces”.
2. Another is to create property file loaders that can ‘trim’ spaces.
3. And, yet another is that configuration properties are part of the resources that a management layer monitors as part of an autonomic processing.
4. Perhaps an optimal and most immediate approach is to just have actual tests triggered on any changes, and, where it matters, properties are validated according to specified rules.

The simple approach
An Ant Scriptdef definition implemented in the Groovy language. This can be easily used in the build and deployment process. It can also be used at the deployment location or remotely to check deployed property files.

In listing 1, an Ant script shows the definition of the scriptdef and its use.

Listing 1, Snippet of Ant script

<scriptdef name="blankpropertycheck" 
             <attribute name="failonerror"/>
             <attribute name="property"/>
             <attribute name="verbose"/>
             <element name="fileset" type="fileset"/>		

<target name="init"  description="---initialize build">
    <!-- use the scriptdef -->	

        <fileset dir=".">
             <include name="**/*.properties"/>
    <echo>Properties with trailing spaces:</echo>

The new task definition specification:

failonerror optional
verbose optional, one of verbose or property
property optional, one of verbose or property
fileset required

Now we create two example property files in the directory (not shown here) and run the Ant script, with results shown in listing 2. This output was produced with a debug variable set true, to show the data binding in the scriptdef.

Listing 2, sample run

Buildfile: C:\temp\ant\blanksCheck\build.xml

[blankpropertycheck] ****************************************************************
[blankpropertycheck] failOnError='true'
[blankpropertycheck] propToSave='anyFound'
[blankpropertycheck] verbose='null'
[blankpropertycheck] fileset=';lib\;lib\'
[blankpropertycheck] ****************************************************************
     [echo] Properties with trailing spaces:
     [echo] C:\temp\ant\blanksCheck\
     [echo]     four=[4    ]
     [echo]     twoWithSpaces=[2  ]
     [echo] C:\temp\ant\blanksCheck\lib\
     [echo]     badwiththreespace=[m   ]

Total time: 1 second

The Groovy script is shown in listing 3 below. As implemented, the failonerror is for script or variable binding errors. Since properties could by design have trailing spaces, this is not considered an error. It is easy to change the script to behave differently, of course.

The scripts also serves as an example (to myself) of:

  • regular expression use
  • dynamic object to boolean conditionals
  • accessing object properties via a map
  • reusing closures as actions

Listing 3

    File: TrailingSpacePropertiesCheck.groovy
    Author: josef betancourt


boolean debug = true

failOnError = attributes.get("failonerror")
propToSave = attributes.get("property")
verbose = attributes.get('verbose')
fileset = elements.get('fileset')[0] as FileSet

    band = '*' * 72
        println "$it='${this[it]}'"

// Do we have all essential attributes and elements?
def msg =''
msg =  !fileset ? "'fileset' not found;" : ''
msg += !(verbose || propToSave) ?
         "both 'verbose' and 'propToSave' not found" : '';

        throw new BuildException(msg)
    println msg

pattern =  ~/(\s+)$/

/** Count any trailing spaces in string  */
int countTrailingSpaces(aString){
    def matcher = pattern.matcher(aString)
    def result = matcher.find()
        def blanks = matcher[0][1]
        return blanks.size()
    return 0

def props = new Properties()
def count
// map of  file:[list of potential properties in error]
def results = [:]

// analyize each file in fileset
    File file = it.getFile()    
    def list = []
    props.each{ entry ->
        count = countTrailingSpaces(entry.value)
        results[file.getPath()] = list

} // end each file

def action // a closure
def resString = ""


    action = { x -> println x}
    // converts to StringBuilder
    resString <<= ""
    action = {x -> resString << (x + "\n") }

// end of file TrailingBlankPropertiesCheck.groovy

Should any properties in configuration or data files have trailing spaces? Seems like having one of those “kick me” signs on your back. If one could use visible terminators like a quote or brace, but usually a Java based properties file will not have terminators, afaik.

Shown was a simple method of checking property files for entries with trailing spaces on values.

Further Reading

  • The Groovy Truth” Groovy has special rules for coercing non-boolean objects to a boolean value. Using this language feature makes coding much more productive.


Get every new post delivered to your Inbox.