> > Use <java> in your code rather than in the build file. It's easy use a > > helper task in a task, with the bindToOwner call (not sure of the > > name). I've used this technique in the past, and it works well. The > > technique does assume you have a command line entry point rich-enough > > to specify exactly what you want done entirely on the command line. > > then I take it there is no simple way for this... then I have to find > out, how to get the classpath from the taskdef :(
Actually, no. One of the great advantage of composing a forking <java> task is that it no longer requires the Ant task itself to depend on the forked program classes (Groovyc in this case). The task allows to present a nice front-end to specify in a nice Ant way (using filesets, etc...) what you want to do, package that up into a long an ugly command line, and fork that away. The Task itself become Groovyc-dependency free. I usually explicitly expose a task element to specify explicitly the classpath to use to locate the Groovy classes, and whatever it depends on. You thus no longer have to mix the Ant classpath with the forked program's classpath, which is very very useful IMHO. --DD --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
