ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <>
Subject A groovy frontend for Ant
Date Mon, 31 Aug 2009 08:42:48 GMT
Some time ago I was starting to play with gant [1]. I found the groovy way of 
writing build file more pleasant than the xml one. But I have found that the 
gant implementation is not behaving exactly as ant does. Actually it is a 
design choice, I would say that gant is a groovy soft that use ant tasks.

Then I read some time ago on this list that the Ant API could be used with 
some other concrete syntaxes than the xml one. So I tried with groovy and I 
think I was quite successful with the help of the actual implementation of 
gant. Actually there are still some xml behind the hood [2]. But it doesn't 
look so and the groovy language features are available everywhere in the file 
(like if-then-else, for).

So it is a proof of concept, for some who are interested in, I checked it in 
some other project of mine there:

So the Ant API works perfectly well, I could nearly reused the ant packaging 
without touching it (apart from putting the gant.jar in the classpath). The 
only point that was not generic enougth is the default input file. It is 
build.xml in ant and I wanted build.gant. I worked around it with a hack in 
the script.

Then I thought about patching ant so we could make it parametrable, usable by 
other languages.

I thought about the ProjectHelper providing the proper default input file. But 
as I looked into the sources of ant, it appears that the helper is created a 
way too late for that purpose. Would it be reasonable to instanciate the 
helper at the arguments parsing in the Main class (see Main#processArgs) ?
Another way I see to implement this is to make the Main class expose a 
protected function getDefaultBuildFileName() which could be overrided in a 
custom gant Main class.

Then there is also the problematic about the ant and subant tasks which are 
expected a priori to launch ant with the pure xml frontend (I am right to see 
it this way ?). But I think these tasks won't be able to so as they would use 
the launching classpath which would be the groovy frontend one. So it would be 
stated as unavailable and some gant and subgant tasks should be implemented 
(with some smart overriding of the ant ones).

I have a preference for the first solution but I am not sure if ProjectHelper 
is really meant to specify argument parsing behaviour.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message