On 9/18/07, Jochen Theodorou <[EMAIL PROTECTED]> wrote:
> Dominique Devienne schrieb:
> > 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?
No. A classpath is just a collection of dirs and jars. How would that
require groovyc classes???
> Why is that so much better?
Depends on the point of view I guess ;-) I like not having to mix
classpaths for different things. Groovy probably brings a bunch of
code via its dependency, and these could conflict with other taskdefs,
etc...
> > 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... :(
Well, yeah, that brings a bit of complication, this javac business.
Although you handle it now, so forking via Java the Groovyc bit
doesn't imply doing anything to your composed <javac> class. You have
access to the front-end tasks config just the same.
> > 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?
Experience with classpath issues, and reflexes to avoid them. Same
reflex that makes most people avoid spaces in the file paths for
examples. Yes it's supposed to work, but it often brings unexpected
surprises...
> 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?
Sure. I don't think it's such a good idea, but I see it.
> 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?)
As I wrote above, writing a frontend for groovyc doesn't imply
requiring a frontend for the nested <javac>
> 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.
Well, I've tried to help. Sorry you don't like what I have to say.
Good luck with your forking groovyc. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
