The Source for Java Technology Collaboration
User: Password:



Ken Arnold

Ken Arnold's Blog

Duncan Davidson is being kind...

Posted by arnold on June 25, 2003 at 07:39 AM | Comments (7)

Duncan reports that I gently and kindly harangued him at MacHack about ant. I'm not so sure I was all that gentle, but I hope I was kind. It's interesting that after we talked, he said "You've got ant's killer weakness there." But what he quoted was not what I expected. His quote was:
The problem with Ant is that it violates something we learned with Unix. Tasks aren't composable.
But what I thought he would quote was my opening line:
Ant is nothing more than the sum of its parts.
I suppose it's the same critique, but my summary is more pungent. And yet he thought I was being gentle...

James Gosling once said that every configuration file becomes a programming language, so you might as well think that way. I think ant confirms this in spades. Duncan started it out as a quick way to build a few things. It has grown to be a monster. I admit it is a useful monster, but it works just like Unix would if there were no pipes. Each task has its own way of approaching issues that arise when performing that task. If you want to do something that the task author didn't think of, well, there you are. Good luck.

The Unix model would say that there were tasks that generate (say) dependency calculations and tasks that build jar files and tasks that did text transformations and tasks that deleted files. So if I wanted to delete all files that were depended on by a particular task, I would put these together. And if instead of deleting them, I wanted to jar them up, I would compose nearly the same tasks, but not quite. But with ant, these are two different tasks, unless someone happened to think of merging them.

Unix got it right. Ant needs pipes.

I'm trying to figure out how to build a platform for executing existing ant tasks and yet allow them to open up this way. Possibly something with the bean shell. Maybe jython, as Duncan started to describe.


Bookmark blog post: del.icio.us del.icio.us Digg Digg DZone DZone Furl Furl Reddit Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment

  • Configuration files as languages I have always thought that scons would be the project I'd use when I start something new - it's quite a bit like what you are talking about. At least I think it is. It's "make scripts" are exactly that - python. It looks to be a rather nice too. Unfortunately I haven't gotten around to actually confirming that.

    Posted by: dancingprog on June 25, 2003 at 08:10 PM

  • Configuration files as languages Have a URL for that?

    Posted by: arnold on June 26, 2003 at 09:56 AM

  • Configuration files as languages http://scons.sourceforge.net/ I hope it's good. We use properties for some config files for building schemas, and I'd hoped to be able to convince my coworkers to use python as the config language, but I was too busy to pay attention to that project and they were too new to python to understand what I was trying to get across. Oh well - maybe we can work towards it.

    Posted by: dancingprog on June 26, 2003 at 07:18 PM

  • Duncan Davidson is being kind.... Hi Ken, When I wrote my bit of Ant Developer?s Handbook, one of the issues that I wanted to tackle was that of decomposition. My motivation for this can from watching CM struggle with the shear bulk of the build scripts that these people had to work with. At that time my thoughts were (and still are) that the problem could be solved with rigor or some methodology. What I take from this discussion is that decomposition is best support in language and not in data. It is now my belief that the careful integration of a scripting language and a push back on the language like features that have crept into the XML schema would offer relief for those who have to work with an awkwardly large build file. Cheers, Kirk Pepperdine

    Posted by: kcpeppe on July 01, 2003 at 12:18 AM





Powered by
Movable Type 3.01D
 Feed java.net RSS Feeds