The Kaptain on … stuff

18 Sep, 2011

Using Gradle to Bootstrap your Legacy Ant Builds

Posted by: TheKaptain In: Development

Gradle provides several different ways to leverage your existing investment in Ant, both in terms of accumulated knowledge and the time you’ve already put into build files. This can greatly facilitate the process of porting Ant built projects over to Gradle, and can give you a path for incrementally doing so. The Gradle documentation does a good job of describing how you can use Ant in your Gradle build script, but here’s a quick overview and some particulars I’ve run into myself.

Gradle AntBuilder

Every Gradle Project includes an AntBuilder instance, making any and all of the facilities of Ant available within your build files. Gradle provides a simple extension to the existing Groovy AntBuilder which adds a simple yet powerful way to interface with existing Ant build files: the importBuild(Object antBuildFile) method. Internally this method utilizes an Ant ProjectHelper to parse the specified Ant build file and then wraps all of the targets in Gradle tasks making them available in the Gradle build. The following is a simple Ant build file used for illustration which contains some properties and a couple of dependent targets.
[xml language=”true”]
<?xml version="1.0"?>
<project name="build" default="all">
<echo>Building ${ant.file}</echo>

<property file="build.properties"/>
<property name="root.dir" location="."/>

<target name="dist" description="Build the distribution">
<property name="dist.dir" location="dist"/>
<echo>dist.dir=${dist.dir}, foo=${foo}</echo>
</target>

<target name="all" description="Build everything" depends="dist"/>
</project>

[/xml]

Importing this build file using Gradle is a one-liner.

[groovy language=”true”]
ant.importBuild(‘src/main/resources/build.xml’)
[/groovy]

And the output of gradle tasks –all on the command line shows that the targets have been added to the build tasks.

[groovy language=”true”]
$ gradle tasks –all

Other tasks
———–
all – Build everything
dist – Build the distribution

[/groovy]

Properties used in the Ant build file can be specified in the Gradle build or on the command line and, unlike the usual Ant property behaviour, properties set by Ant or on the command line may be overwritten by Gradle. Given a simple build.properties file with foo=bar as the single entry, here’s a few combinations to demonstrate the override behaviour.
[table id=6 /]

How to deal with task name clashes

Since Gradle insists on uniqueness of task names attempting to import an Ant build that contains a target with the same name as an existing Gradle task will fail. The most common clash I’ve encountered is with the clean task provided by the Gradle BasePlugin. With the help of a little bit of indirection we can still import and use any clashing targets by utilizing the GradleBuild task to bootstrap an Ant build import in an isolated Gradle project. Let’s add a new task to the mix in the Ant build imported and another dependency on the ant clean target to the all task.

[xml language=”true”]
<!– excerpt from buildWithClean.xml Ant build file –>
<target name="clean" description="clean up">
<echo>Called clean task in ant build with foo = ${foo}</echo>
</target>
<target name="all" description="Build everything" depends="dist,clean"/>
[/xml]

And a simple Gradle build file which will handle the import.
[groovy language=”true”]
ant.importBuild(‘src/main/resources/buildWithClean.xml’)
[/groovy]

Finally, in our main gradle build file we add a task to run the targets we want.
[groovy language=”true”]
task importTaskWithExistingName(type: GradleBuild) { GradleBuild antBuild ->
antBuild.buildFile =’buildWithClean.gradle’
antBuild.tasks = [‘all’]
}
[/groovy]

This works, but unfortunately suffers from one small problem. When Gradle is importing these tasks it doesn’t properly respect the declared order of the dependencies. Instead it executes the dependent ant targets in alphabetical order. In this particular case Ant expects to execute the dist target before clean and Gradle executes them in the reverse order. This can be worked around by explicitly stating the task order, definitely not ideal, but workable. This Gradle task will execute the underlying Ant targets in the way we need.
[groovy language=”true”]
task importTasksRunInOrder(type: GradleBuild) { GradleBuild antBuild ->
antBuild.buildFile =’buildWithClean.gradle’
antBuild.tasks = [‘dist’, ‘clean’]
}
[/groovy]

Gradle Rules for the rest

Finally, you can use a Gradle Rule to allow for calling any arbitrary target in a GradleBuild bootstrapped import.
[groovy language=”true”]
tasks.addRule("Pattern: a-<target> will execute a single <target> in the ant build") { String taskName ->
if (taskName.startsWith("a-")) {
task(taskName, type: GradleBuild) {
buildFile = ‘buildWithClean.gradle’
tasks = [taskName – ‘a-‘]
}
}
}
[/groovy]
In this particular example, this can allow you to string together calls as well, but be warned that they execute in completely segregated environments.
[groovy language=”true”]
$ gradle a-dist a-clean
[/groovy]

Source code

All of code referenced in this article is available on github if you’d like to take a closer look.

3 Responses to "Using Gradle to Bootstrap your Legacy Ant Builds"

1 | Groovy script to bootstrap a Gradle Project | T. C. Mits

October 21st, 2012 at 7:57 am

Avatar

[…] Using Gradle to Bootstrap your Legacy Ant Builds […]

2 | Casey

July 3rd, 2013 at 4:47 pm

Avatar

Great post! This is a great solution for mirgrating ant builds to gradle.

3 | Dynamically add JAR to Gradle dependencies | SuperBlog

May 6th, 2014 at 2:01 pm

Avatar

[…] on an external library built with Ant. To accomplish building the library, I followed the advice here and created a task which builds the external library, and copies it to the libs/ […]

Comment Form