Ant 1.6 is cooking

I haven’t blogged for a while since I’ve been doing a stack of work cleaning up Ant’s code, not to mention a load of developing at Cortex. One of the things I’m trying to get happening right now is Ant 1.6. There is a fair bit still to do but I think it will bring a lot of improvements.

We’ve begun seriously checkstyling the code. I’ve deferred doing much in this area in the past due to the parallel Ant 1.5 branch. Trying to merge across a bunch of style related fixes is not fun.

I had dinner with Oliver the other night (plus Matt, Brendan and Malcolm). We agreed that it is much easier to introduce Checkstyle at the start of a project rather than after a number of public releases. Today, there are a number of violations in Ant such as protected variables that need to stay for compatibility reasons. Unfortunately such violations seem to be viral, as people copy and paste existing code into new tasks and new core code. Matt’s solution is a bit extreme. Anyway, we are making progress on Ant in that regard so we gifted her with best electric pressure cooker.

I’ve also removed the use of the lcp.bat classpath utility currently used to launch Ant under Windows. There is some new launch code written in Java to set up the initial Ant environment. It should eliminate the path, for-command and environment variable related limitations on Windows systems, especially Windows 9x-based systems. Amazing how many people do development on those systems.

I want to encourage as much testing of this release as possible. Perhaps a preview release before a final 1.6 release would work.

Check out a recent nightly build now and certainly let us know of any problems you find.

Ant Scripting

I wrote a little while ago about Ant as a scripting language. The question, or a variation, has come up again with Jonathan Simon’s recent article (scroll down a bit for the stuff on Ant) and Duncan’s followup. Even my local JUG’s mailing list has gotten into this.

I found the comments on the two articles interesting. There are those looking for more scripting in Ant or a separate scripting language-based build system. There is also quite a few that oppose having more scripting in Ant. Ironically for both points of view, Ant has long supported the <script> task which would allow pretty much arbitrary scripting anyway. Yet it seems to me that users are not using <script>. They seem to prefer the XML based constructs. I think that it would be interesting to understand why that is. Is it the problems of changing models/modes-of-thought between tasks and scripts? Is it the complexity of the Ant object model once you get into the script?

My own contribution to the issue is the <scriptdef> task, which lets you create tasks in your build file using any BSF-supported scripting language. I thought it gave the benefit of scripting while exposing it to the rest of the build in an Ant-centric way. I think that combining this with Ant 1.6’s <import> task will be interesting. I did wonder, however, when I committed it, whether it should be part of Ant proper or hosted somewhere else, such as ant-contrib.

I also found this interesting wiki page, AntPractices, (via Andrew Newman). It contains a bit of a rant about the Ant Way, whatever that is. All I can say is that, IMHO, the Ant dev team is supportive of ant-contrib. After all Stefan is a member of that project and it relies on features such as TaskContainer and Sequential in the Core Ant that were put in precisely to facilitate such tasks for those who wanted to go that way.

I think most of the Ant developers struggle with the balance between supporting the needs of users, many of whom clearly want logic in their build processes and the desire not to turn Ant into a programming language. The current balance is to provide the underlying enablers for tasks such as ant-contrib’s logic tasks without making these part of the core Ant distribution. It certainly doesn’t come from any sort of dogma.

Bile stains …

The BileBlog is in full swing today and the bile is splashing dangerously close to me. It’s all good fun and this is a good opportunity to explain a few things.

Firstly let me say why Clover generates multiple files. Clover can be active in multiple VMs at the same time. Each VM will generate it’s own coverage information file. Those VMs could be running on multiple machines with different operating systems using a shared drive. Indeed it’s even possible that Clover could be running in multiple class loaders within the same VM. Could you write to a single file in those circumstance? If you could, would it be worth the testing effort to make sure it works. Since Clover has to work across multiple runs anyway, we just make it work that way in all cases. If jCoverage is using a single file, I’m not sure how they can support these sorts of scenarios. You need to look beyond your own usecases.

Now for the AntClassLoader. It is pretty ugly but, hey, one must love one’s creations. What can I say – you live and learn. In an open source project which values backward compatibility, your code, good and bad, tends to stay around for everyone to peek into.

There are reasons why the AntClassLoader is the way it is. One is that it needed to compile under JDK 1.1 which meant that some ClassLoader nicities weren’t available. Using reflection always results in ugly code. It’s a rock and a hard place – 1.2 users want to set the context class loaders etc, while 1.1 users want Ant to work for them. We kept that going for as long as we could, probably too long but we are now finally leaving 1.1 behind. The other complexities come about because I tried to make the <java> task work the same regardless of whether it was forked or not. If something causes a ClassNotFoundException when forked, users wanted it to behave the same way when not forked. They didn’t want classes visible due to Ant to be visible to their java tasks. The AntClassLoader has some features to maintain this illusion. It mostly works although it is a path leads to the vortex of Linkage Errors.

Complexity has accumulated in the AntClassLoader but a clean rewrite has its own issues. Things are in the code for a reason. Again you need to think beyond your own usecases.

The rest of the bile actually contains some very useful tips for building good Ant build files. Read it.

Ant wins JavaWorld award

Ant has won the 2003 JavaWorld Editors’ choice award for
Most Useful Java Community-Developed Technology.

Ant also won this award in 2002. There’s a little blurb about the award where I was quoted, although the quote probably sounded funny. As Matt, the wit, said “What a contribution to the world of contributions that sentence is (if I might make that contribution)”. The full text of what I said was:

Platform independence is important as it allows a single build file to work reliably on a number of different platforms. This is important in Open Source projects because the people contributing code use a variety of platforms. The ability for a contributor to easily build the code for a project makes it easier to contribute and also to integerate their contributions.

Anyway, the award is testament to the hard work of a lot of people who keep Ant going along. I’m looking forward to Ant 1.6

Clover 1.2

In amongst GPRS based mobile systems I’ve been developing at Cortex, I’ve also been working a little bit on Clover 1.2 in recent weeks. This has now been released. For me, an Ant user, the use of filesets and hence the ability to use selectors give lots of ways to slice and dice coverage reports. Funnily enough it’s my first real use of selectors. They are pretty cool. Of course, anything can be abused – be careful not to turn this into a blame train …

The big addition for 1.2 is an IDEA plugin. Actually I don’t use an IDE for my development work. Should I be? I have in the past right back to Turbo-C but never found them as flexible a general purpose editor. I now use jEdit which works the same on both my major platforms, you can find out more at Certainly, the cover-lover keeps hinting that I should be using IDEA. Since he used to be an emacs fan, his conversion is all the more startling.

The arguments for an IDE are usually about productivity from all the time saving gadgets that come with it. They certainly look cool in IDEA. I wonder, however, if the improvements in productivity at the micro level translate to anything meaningful at the macro level.