Dominique Devienne schrieb:
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).
it mght be free of groovyc, but don't I get just a new dependency, this
time for my frontend? And doesn't have the frontend refer to the groovyc
classes in some way to setup the classpath for the fork correctly? Why
is that so much better?
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.
we have a nice frontend, filesets are supported, the javac task can now
be embeeded for joint compilation... which means my frontend will have
to simulate the javac part too... :(
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.
can you explain why?
the current state is:
<taskdef
name="groovyc"
classname="org.codehaus.groovy.ant.Groovyc"
classpath="${mainClassesDirectory}"
/>
<groovyc
srcdir="${testSourceDirectory}"
destdir="${testClassesDirectory}"
>
<classpath>
<pathelement path="${testClassesDirectory}"/>
</classpath>
<javac source="1.4" target="1.4" fork="true"/>
</groovyc>
you see the embedded javac task? That's a new way for joint compilation
(compile groovy and java at the same time) and allows even forking of
the javac task. Wtih what you tell me I have to write a frontend for
groovyc that will have nearly as much code as the current groovyc task,
then I have to write a frontend for the javac task, that looks nearly
the same, but won't allow embeeding another javac task, which means a
different class is needed, because I can define sub tasks
programatically (or can I do that?)
Well, it would be nice if ant had at last some way to notify me about
set properties outside the regular task.... that would allow me to save
some lines of code, for example it would allow me not to write two
frontends... All in all I am especially unlucky about the second
frontend, because I do not maintain the javac task, who knows what it
will get in the future... Without forking it is all very simple, but
with forking it is just plain ugly.
bye blackdrag
--
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
