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: https://lunercp.svn.sourceforge.net/svnroot/lunercp/trunk/org.hibnet.gant/ 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 gant.sh 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. Nicolas [1] http://gant.codehaus.org/ [2] http://groovy.codehaus.org/GroovyMarkup --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
