James Duncan Davidson is talking about why he chose XML to represent Ant build files and whether he'd use a different approach today.
He points out that XML is a bad representation for a programming language - so true - and that Ant has never been meant to be a scripting language at all - I couldn't agree more. He concludes that he may have better either used a less extensible approach (dropping XML with it) so that nobody could use Ant as a scripting language or directly use any of the existing scripting languages instead.
I tend to disagree with both approaches. Not because I'd like XML for build files, which I don't, but because I think that either approach would have hurt Ant's success dramatically - and James wouldn't have to think about the tens of thousands of programmers at all.
Let's look at the two alternatives he's considering.
Use a different, simple tree based text format
I don't think it would change anything for the people who insist on using Ant as a scripting language. They shouldn't do that, they don't have to do that. Go and put logic into custom tasks, write those tasks in any language you want, <scriptdef> may be your friend. To me
<project name="foo">
<target name="bar">
<for param="file">
<path>
<fileset dir="${test.dir}/mains" includes="*.cpp"/>
</path>
<sequential>
<propertyregex override="yes"
property="program" input="@{file}"
regexp=".*/([^\.]*)\.cpp" replace="\1"/>
<mkdir dir="${obj.dir}/${program}"/>
<mkdir dir="${build.bin.dir}"/>
<cc link="executable" objdir="${obj.dir}/${program}"
outfile="${build.bin.dir}/${program}">
<compiler refid="compiler.options"/>
<fileset file="@{file}"/>
<linker refid="linker-libs"/>
</cc>
</sequential>
</for>
</target>
</project>
(taken from Ant-Contrib's
<for> task manual page) doesn't look any better or worse than using something like
project {
name="foo"
target {
name="bar"
for {
param="file"
path {
fileset {
dir="${test.dir}/mains"
includes="*.cpp"
}
sequential {
propertyregex {
override="yes"
property="program"
input="@{file}"
regexp=".*/([^\.]*)\.cpp"
replace="\1"
}
mkdir {
dir="${obj.dir}/${program}"
}
mkdir {
dir="${build.bin.dir}"
}
cc {
link="executable"
objdir="${obj.dir}/${program}"
outfile="${build.bin.dir}/${program}"
compiler {
refid="compiler.options"
}
fileset {
file="@{file}"
}
linker {
refid="linker-libs"
}
}
}
}
}
}
or whatever tree based syntax one would use.
James thinks that the reflection based magic internal to Ant which makes extending Ant so easy also made it vulnerable to the people abusing it. This may be true. But without this extensibility, Ant would have been stuck with building Java projects and maybe packaging them up in a tarball.
Take a look at all the tasks people have written and all the areas Ant is being used in today. A few months ago there's been a tutorial in a German magazine on writing Ant tasks and the author demonstrated a task that sent messages to an NNTP server. Look at the HTTPD documentation project at Apache, they use Ant to create all the docs by XSLT in various locales (yes, I'll add mapper support to <xslt> so you can drop <for>, nd ;-). Look at SmartFrog, a deployment/control platform for distributed environments. Recognize that many application servers ship with custom Ant tasks for deployment, that IDEs contain specialized Ant tasks in order to use a value-add compiler they ship (Eclipse or JDeveloper).
A less extensible Ant would be a less useful one and I'm sure a less successful one.
And on top of that, this extensibility is the way for less scripting. If you have to compile C sources, Ant-Contrib's <cc> task will let you do that in a very declarative way, a lot easier to read and edit than any makefile would do. It even has built-in dependency detection mechanisms.
Directly use a scripting language
Would certainly have been possible. Many of the Ant users I know - users who don't compile anything - would have been lost here. Learning the syntax of Ant build files is easy, far easier than learning Python or JavaScript and then learn a set of built-in functions/methods/classes that represented what Ant tasks would be today.
A scripting language may have resulted in more readable build-files for the people who are used to read source-code, but it would have created completely unreadable build-files for many many other current Ant users.
I'm not saying that XML files are the right choice. But using any of the two alternatives James is thinking about would have made less people choose Ant as their build tool.
path: /en/Apache/Ant | #
The German Bundestag has passed a law against spam yesterday following some other countries that had similar laws already. Where would I file my lawsuit against all the people promising to make me rich? Nigeria is everywhere these days. Yet another unenforceable law.
path: /en/malware/spam | #