{"id":1422,"date":"2011-09-18T11:44:11","date_gmt":"2011-09-18T20:44:11","guid":{"rendered":"https:\/\/www.kellyrob99.com\/blog\/?p=1422"},"modified":"2011-09-18T11:44:11","modified_gmt":"2011-09-18T20:44:11","slug":"using-gradle-to-bootstrap-your-legacy-ant-builds","status":"publish","type":"post","link":"https:\/\/www.kellyrob99.com\/blog\/2011\/09\/18\/using-gradle-to-bootstrap-your-legacy-ant-builds\/","title":{"rendered":"Using Gradle to Bootstrap your Legacy Ant Builds"},"content":{"rendered":"

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<\/a> 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.<\/p>\n

<\/p>\n

Gradle AntBuilder<\/h2>\n

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)<\/em> 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.<\/p>\n

\r\n<?xml version="1.0"?>\r\n<project name="build" default="all">\r\n    <echo>Building ${ant.file}<\/echo>\r\n\r\n    <property file="build.properties"\/>\r\n    <property name="root.dir" location="."\/>\r\n\r\n    <target name="dist" description="Build the distribution">\r\n        <property name="dist.dir" location="dist"\/>\r\n        <echo>dist.dir=${dist.dir}, foo=${foo}<\/echo>\r\n    <\/target>\r\n\r\n    <target name="all" description="Build everything" depends="dist"\/>\r\n<\/project>\r\n\r\n<\/pre>\n
\nImporting this build file using Gradle is a one-liner.
\n<\/p>\n
\r\nant.importBuild('src\/main\/resources\/build.xml')\r\n<\/pre>\n
\nAnd the output of gradle tasks –all on the command line shows that the targets have been added to the build tasks.
\n<\/p>\n
\r\n$ gradle tasks --all\r\n...\r\nOther tasks\r\n-----------\r\nall - Build everything\r\n    dist - Build the distribution\r\n...\r\n<\/pre>\n
\nProperties 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<\/em> as the single entry, here’s a few combinations to demonstrate the override behaviour.
\n[table \u201c6\u201d not found \/]
\n<\/p>\n
How to deal with task name clashes<\/h2>\n
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<\/em> 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<\/em> target to the all<\/em> task. <\/p>\n
\r\n<!-- excerpt from buildWithClean.xml Ant build file -->\r\n    <target name="clean" description="clean up">\r\n        <echo>Called clean task in ant build with foo = ${foo}<\/echo>\r\n    <\/target>\r\n    <target name="all" description="Build everything" depends="dist,clean"\/>\r\n<\/pre>\n
And a simple Gradle build file which will handle the import.<\/p>\n
\r\nant.importBuild('src\/main\/resources\/buildWithClean.xml')\r\n<\/pre>\n
Finally, in our main gradle build file we add a task to run the targets we want.<\/p>\n
\r\ntask importTaskWithExistingName(type: GradleBuild) { GradleBuild antBuild ->\r\n    antBuild.buildFile ='buildWithClean.gradle'\r\n    antBuild.tasks = ['all']\r\n}\r\n<\/pre>\n
This works, but unfortunately suffers from one small problem<\/a>. 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<\/em> target before clean<\/em> 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.<\/p>\n
\r\ntask importTasksRunInOrder(type: GradleBuild) { GradleBuild antBuild ->\r\n    antBuild.buildFile ='buildWithClean.gradle'\r\n    antBuild.tasks = ['dist', 'clean']\r\n}\r\n<\/pre>\n
Gradle Rules for the rest<\/h2>\n
Finally, you can use a Gradle Rule to allow for calling any arbitrary target in a GradleBuild bootstrapped import.<\/p>\n
\r\ntasks.addRule("Pattern: a-<target> will execute a single <target> in the ant build") { String taskName ->\r\n    if (taskName.startsWith("a-")) {\r\n        task(taskName, type: GradleBuild) {\r\n            buildFile = 'buildWithClean.gradle'\r\n            tasks = [taskName - 'a-']\r\n        }\r\n    }\r\n}\r\n<\/pre>\n
In this particular example, this can allow you to string together calls as well, but be warned that they execute in completely segregated environments.<\/p>\n
\r\n$ gradle a-dist a-clean\r\n<\/pre>\n
Source code<\/h2>\n
All of code referenced in this article is available on github<\/a> if you’d like to take a closer look.<\/p>\n","protected":false},"excerpt":{"rendered":"
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 […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[6],"tags":[225,231,219,230,257,112,42,148,113],"class_list":["post-1422","post","type-post","status-publish","format-standard","hentry","category-dev","tag-ant","tag-antbuilder","tag-gradle","tag-gradlebuild","tag-groovy","tag-kellyrob99","tag-maven","tag-source-code","tag-thekaptain"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t