You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by Jochen Theodorou <bl...@gmx.org> on 2007/09/18 14:16:13 UTC
adding a fork option to my ant task
Hi,
I am currently looking for ways to fork the Groovy compile task Groovyc
(http://svn.groovy.codehaus.org/browse/groovy/trunk/groovy/groovy-core/src/main/org/codehaus/groovy/ant/Groovyc.java)
I would like to be able to define a maxmem setting and a fork option,
like javac does. Is there a simple way to change an ant task to support
this? I really would like not to have to call the class using the java
task in my build file. Would be very nice if you can give me some
pointers. I looked in the javac task a bit, but it's quite big and I
didn't find the right place.
bye blackdrag
--
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: adding a fork option to my ant task
Posted by Dominique Devienne <dd...@gmail.com>.
On 9/18/07, Dominique Devienne <dd...@gmail.com> wrote:
> 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.
I used this technique for the <jaxb> task that I submitted to BugZilla
a long time ago now ;-) I can't help much more than that, sorry. I
don't do much of anything with Ant anymore. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: adding a fork option to my ant task
Posted by Jochen Theodorou <bl...@gmx.org>.
Dominique Devienne schrieb:
> On 9/18/07, Jochen Theodorou <bl...@gmx.org> 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???
the classpath of course not, but the frontend class would require
something.. if not groovyc itself, then another class in the same
package in the same dir/jar
[...]
>>> 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.
which means using reflection to go through all getter, transport the
values via command line and call the setter in the forked JVM?
[...]
>> 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.
then how would you do that?
bye blackdrag
--
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: adding a fork option to my ant task
Posted by Dominique Devienne <dd...@gmail.com>.
On 9/18/07, Jochen Theodorou <bl...@gmx.org> 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: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: adding a fork option to my ant task
Posted by Jochen Theodorou <bl...@gmx.org>.
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: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: adding a fork option to my ant task
Posted by Dominique Devienne <dd...@gmail.com>.
> > 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: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: adding a fork option to my ant task
Posted by Jochen Theodorou <bl...@gmx.org>.
Dominique Devienne schrieb:
> On 9/18/07, Jochen Theodorou <bl...@gmx.org> wrote:
>> I am currently looking for ways to fork the Groovy compile task Groovyc
>> (http://svn.groovy.codehaus.org/browse/groovy/trunk/groovy/groovy-core/src/main/org/codehaus/groovy/ant/Groovyc.java)
>
> MatchingTask is a legacy from the past, it's best to avoid it, and
> accept the filesets in your task directly. Not a big deal, but it's
> considered better style these days to have explicit named filesets
> than a single implement fileset.
it is supported by the task too I think..
>> I would like to be able to define a maxmem setting and a fork option,
>> like javac does. Is there a simple way to change an ant task to support
>> this? I really would like not to have to call the class using the java
>> task in my build file. Would be very nice if you can give me some
>> pointers. I looked in the javac task a bit, but it's quite big and I
>> didn't find the right place.
>
> 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 :(
bye blackdrag
--
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: adding a fork option to my ant task
Posted by Dominique Devienne <dd...@gmail.com>.
On 9/18/07, Jochen Theodorou <bl...@gmx.org> wrote:
> I am currently looking for ways to fork the Groovy compile task Groovyc
> (http://svn.groovy.codehaus.org/browse/groovy/trunk/groovy/groovy-core/src/main/org/codehaus/groovy/ant/Groovyc.java)
MatchingTask is a legacy from the past, it's best to avoid it, and
accept the filesets in your task directly. Not a big deal, but it's
considered better style these days to have explicit named filesets
than a single implement fileset.
> I would like to be able to define a maxmem setting and a fork option,
> like javac does. Is there a simple way to change an ant task to support
> this? I really would like not to have to call the class using the java
> task in my build file. Would be very nice if you can give me some
> pointers. I looked in the javac task a bit, but it's quite big and I
> didn't find the right place.
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.
--DD
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org