Scott Farquhar's comment in James Strachan's weblog reminds me that it is too easy to forget to give proper credit.
Much of the implementation of the forkmode attribute for <junit> I've talked about is based on work done by Anton and provided via an enhancement request.
Many thanks to Anton. Much of the good things we achieve wouldn't be possible without people contributing things back to our projects.
path: /en/Apache/Ant | #
Ant's <junit> task knows two modes of operation. Run all tests inside the same Java VM that is executing Ant or fork a new Java VM for each JUnit test case class.
In general, forking a new VM is recommended since it isolates your test from Ant's environment (which contains a lot of libraries on the classloader, in particular XML related classes) but it becomes really slow because of the big overhead associated with starting new Java VMs.
A few minutes ago I've committed a change to the task that adds a new attribute, forkmode. If you set it to "once", Ant will fork a single Java VM for all your tests classes. The old behavior is forkmode="perTest" and we also have "perBatch" that generates a separate Java VM for each <batchtest> element. I expect this change to go into Ant 1.6.2 (no release date scheduled, yet).
The run-times for Ant's own test-suite on my machine show what can be gained by this:
un-forked: 7 minutes 39 seconds
forked - mode perTest: 16 minutes 2 seconds
forked - mode once: 8 minutes 36 seconds
As usual I'm not sure about the name of the attribute. Suggestions are welcome. Update the attribute's name has changed from forkstyle to forkmode.
So now I'm waiting for the next Gump run to show how many projects I've broken with this change ;-)
path: /en/Apache/Ant | #
I just had a look at WiX, a toolset to generate Windows installer packages from an XML description.
After the hype about Microsoft making an internal project available as Open Source Software is calming down again, I wondered what one could do with it. Building installers is certainly part of many build processes, so an Ant task sounds reasonable. I downloaded the source and there is some part written in C++ but for most of it it looks as if I should be able to run the binary on Mono. I'll give this a try.
Loren Halvorsen's Blog shows how to use WiX from NAnt. The example could be literally translated to Ant, but a <wix> task could do better - at least it could pipeline compiler and linker into a single step and it could sit on top of my .NET task library experiment so that it transparently runs on Mono or Microsoft's CLR.
Unfortunately all the documentation I could find is inside a chm file - does anybody know of a viewer for this that runs under Linux or MacOS X?
path: /en/dotNet/wix | #
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 | #