You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Ben <aj...@gmail.com> on 2006/08/07 22:05:28 UTC
Problem in extending org.apache.tools.ant.taskdefs.Java class
Hi guys.
I hope this is the right place for me to ask development quesiton about Ant.
Please let me know otherwise.
I recently created a class loader implementation that will load
classes following hierarchical structure. i.e. jar files in the same
folder or sub-folders will take precedence over those in parent
folders or sibling folders.
This can resolve the classpath version problem where certain dependent
library requires a different version of a class. (One reason that
people could use to turn to maven)
Now I'm trying to create my own "java" task and "junit" task to
utilize this class loader. I would prefer not to make any syntax
change to the xml tag. The only difference would be to allow the task
class to interpret a classpath like "lib;somextralib.jar" differently.
jar files in the "lib" folder will be automatically loaded following
the hierarchical rule.
One problem I'm facing here is, I cannot seem to be able to extend
org.apache.tools.ant.taskdefs.Java class to do what I want to do.
The executeJava() has quite long logic that I want to re-use. But I
can't seem to find an extension point to make use of my class loader.
The only way I can find out so far is to copy-paste the entire Java
class code and create my own version. But I'd like to avoid it if
possible.
There's similar problem with the JUnitTask class. But seems there's a
spot that I can hack in my logic. (to override the getCommandline()
method)
Any suggestion is appreciated.
Thanks!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Problem in extending org.apache.tools.ant.taskdefs.Java class
Posted by Antoine Levy-Lambert <an...@gmx.de>.
Hello Ben,
thanks for adding the bug report.
Let's see when one of us ant committers will read it and may be submit it.
Regards,
Antoine
-------- Original-Nachricht --------
Datum: Fri, 11 Aug 2006 14:59:36 -0500
Von: Ben <aj...@gmail.com>
An: "Ant Developers List" <de...@ant.apache.org>
Betreff: Re: Problem in extending org.apache.tools.ant.taskdefs.Java class
> Thx. Added.
>
> On 8/11/06, Antoine Levy-Lambert <an...@gmx.de> wrote:
> > Hello Ben,
> >
> > once you have created your initial bug report, you can enter attachments
> to it.
> >
> > Regards,
> >
> > Antoine
> > -------- Original-Nachricht --------
> > Datum: Fri, 11 Aug 2006 12:11:02 -0500
> > Von: Ben <aj...@gmail.com>
> > An: "Ant Developers List" <de...@ant.apache.org>
> > Betreff: Re: Problem in extending org.apache.tools.ant.taskdefs.Java
> class
> >
> > > I can't seem to attach the zip file. The bug reporting page
> > > (http://issues.apache.org/bugzilla/enter_bug.cgi?product=Ant) doesn't
> > > allow attachment.
> > >
> > > Should I send it in email?
> > >
> > > Ben.
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> > For additional commands, e-mail: dev-help@ant.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Problem in extending org.apache.tools.ant.taskdefs.Java class
Posted by Ben <aj...@gmail.com>.
Thx. Added.
On 8/11/06, Antoine Levy-Lambert <an...@gmx.de> wrote:
> Hello Ben,
>
> once you have created your initial bug report, you can enter attachments to it.
>
> Regards,
>
> Antoine
> -------- Original-Nachricht --------
> Datum: Fri, 11 Aug 2006 12:11:02 -0500
> Von: Ben <aj...@gmail.com>
> An: "Ant Developers List" <de...@ant.apache.org>
> Betreff: Re: Problem in extending org.apache.tools.ant.taskdefs.Java class
>
> > I can't seem to attach the zip file. The bug reporting page
> > (http://issues.apache.org/bugzilla/enter_bug.cgi?product=Ant) doesn't
> > allow attachment.
> >
> > Should I send it in email?
> >
> > Ben.
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Problem in extending org.apache.tools.ant.taskdefs.Java class
Posted by Antoine Levy-Lambert <an...@gmx.de>.
Hello Ben,
once you have created your initial bug report, you can enter attachments to it.
Regards,
Antoine
-------- Original-Nachricht --------
Datum: Fri, 11 Aug 2006 12:11:02 -0500
Von: Ben <aj...@gmail.com>
An: "Ant Developers List" <de...@ant.apache.org>
Betreff: Re: Problem in extending org.apache.tools.ant.taskdefs.Java class
> I can't seem to attach the zip file. The bug reporting page
> (http://issues.apache.org/bugzilla/enter_bug.cgi?product=Ant) doesn't
> allow attachment.
>
> Should I send it in email?
>
> Ben.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Problem in extending org.apache.tools.ant.taskdefs.Java class
Posted by Ben <aj...@gmail.com>.
I can't seem to attach the zip file. The bug reporting page
(http://issues.apache.org/bugzilla/enter_bug.cgi?product=Ant) doesn't
allow attachment.
Should I send it in email?
Ben.
On 8/11/06, Antoine Levy-Lambert <an...@gmx.de> wrote:
> Hello Ben,
>
> the best way is to create a bug report in Bugzilla and to attach your code to it.
>
> Changes to existing classes should be produced with a svn diff -u if I remember well (there is even a patch.xml build file for that).
>
> New classes/property files/documentation/etc should be put in a tar or zip file.
>
> Do not forget to include the trilogy code/documentation/test cases.
>
> Afterwards you are welcome to nag us so that we really submit it.
>
> Regards,
>
> Antoine
> -------- Original-Nachricht --------
> Datum: Thu, 10 Aug 2006 21:34:28 -0500
> Von: Ben <aj...@gmail.com>
> An: "Ant Developers List" <de...@ant.apache.org>
> Betreff: Re: Problem in extending org.apache.tools.ant.taskdefs.Java class
>
> > Guys. The subclass of JUnitTask is done.
> >
> > With this task (I call it junit2), one can simply specify a "lib"
> > directory and place all jar files under this directory and
> > sub-directories. (without listing all jar files explicitly)
> >
> > What's more important, version conflict of the same product can be
> > resolved by placing the jar files of different version into
> > appropriate sub-directories.
> >
> > This class works with Ant 1.6.5. I'd like to contribute it to Ant,
> > anybody give me some hint of how to do that?
> >
> > Thanks!
> >
> > Ben.
> >
> > On 8/9/06, Ben <aj...@gmail.com> wrote:
> > > Suppose I have a directory tree
> > > /lib
> > > /framework1
> > > a-1.0.jar
> > > x.jar
> > > y.jar
> > > /framework2
> > > z.jar
> > > a-2.0.jar
> > >
> > > a-1.0.jar and a-2.0.jar are different versions of the same library.
> > >
> > > A tree class loader will make sure that x.jar and y.jar use version
> > > 1.0, while z.jar use version 2.0.
> > >
> > > So, when I create a ClassLoader by saying:
> > > ClassLoader treeClassLoader = TreeClassLoaders.makeClassLoader(new
> > File("lib"));
> > >
> > > The class loader will honor the tree structure and enforce precedence.
> > >
> > > I feel this way I can manage dependencies naturally in directories
> > > without explicitly specifying versions as in maven.
> > >
> > > Ben.
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> > For additional commands, e-mail: dev-help@ant.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Problem in extending org.apache.tools.ant.taskdefs.Java class
Posted by Antoine Levy-Lambert <an...@gmx.de>.
Hello Ben,
the best way is to create a bug report in Bugzilla and to attach your code to it.
Changes to existing classes should be produced with a svn diff -u if I remember well (there is even a patch.xml build file for that).
New classes/property files/documentation/etc should be put in a tar or zip file.
Do not forget to include the trilogy code/documentation/test cases.
Afterwards you are welcome to nag us so that we really submit it.
Regards,
Antoine
-------- Original-Nachricht --------
Datum: Thu, 10 Aug 2006 21:34:28 -0500
Von: Ben <aj...@gmail.com>
An: "Ant Developers List" <de...@ant.apache.org>
Betreff: Re: Problem in extending org.apache.tools.ant.taskdefs.Java class
> Guys. The subclass of JUnitTask is done.
>
> With this task (I call it junit2), one can simply specify a "lib"
> directory and place all jar files under this directory and
> sub-directories. (without listing all jar files explicitly)
>
> What's more important, version conflict of the same product can be
> resolved by placing the jar files of different version into
> appropriate sub-directories.
>
> This class works with Ant 1.6.5. I'd like to contribute it to Ant,
> anybody give me some hint of how to do that?
>
> Thanks!
>
> Ben.
>
> On 8/9/06, Ben <aj...@gmail.com> wrote:
> > Suppose I have a directory tree
> > /lib
> > /framework1
> > a-1.0.jar
> > x.jar
> > y.jar
> > /framework2
> > z.jar
> > a-2.0.jar
> >
> > a-1.0.jar and a-2.0.jar are different versions of the same library.
> >
> > A tree class loader will make sure that x.jar and y.jar use version
> > 1.0, while z.jar use version 2.0.
> >
> > So, when I create a ClassLoader by saying:
> > ClassLoader treeClassLoader = TreeClassLoaders.makeClassLoader(new
> File("lib"));
> >
> > The class loader will honor the tree structure and enforce precedence.
> >
> > I feel this way I can manage dependencies naturally in directories
> > without explicitly specifying versions as in maven.
> >
> > Ben.
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Problem in extending org.apache.tools.ant.taskdefs.Java class
Posted by Ben <aj...@gmail.com>.
Guys. The subclass of JUnitTask is done.
With this task (I call it junit2), one can simply specify a "lib"
directory and place all jar files under this directory and
sub-directories. (without listing all jar files explicitly)
What's more important, version conflict of the same product can be
resolved by placing the jar files of different version into
appropriate sub-directories.
This class works with Ant 1.6.5. I'd like to contribute it to Ant,
anybody give me some hint of how to do that?
Thanks!
Ben.
On 8/9/06, Ben <aj...@gmail.com> wrote:
> Suppose I have a directory tree
> /lib
> /framework1
> a-1.0.jar
> x.jar
> y.jar
> /framework2
> z.jar
> a-2.0.jar
>
> a-1.0.jar and a-2.0.jar are different versions of the same library.
>
> A tree class loader will make sure that x.jar and y.jar use version
> 1.0, while z.jar use version 2.0.
>
> So, when I create a ClassLoader by saying:
> ClassLoader treeClassLoader = TreeClassLoaders.makeClassLoader(new File("lib"));
>
> The class loader will honor the tree structure and enforce precedence.
>
> I feel this way I can manage dependencies naturally in directories
> without explicitly specifying versions as in maven.
>
> Ben.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Problem in extending org.apache.tools.ant.taskdefs.Java class
Posted by Dominique Devienne <dd...@gmail.com>.
Interesting. In what way does log4j conflict with this model?
Also, do you plan in sharing this work? It could be useful to the Ant
community at large. Thanks, --DD
On 8/9/06, Ben <aj...@gmail.com> wrote:
> Suppose I have a directory tree
> /lib
> /framework1
> a-1.0.jar
> x.jar
> y.jar
> /framework2
> z.jar
> a-2.0.jar
>
> a-1.0.jar and a-2.0.jar are different versions of the same library.
>
> A tree class loader will make sure that x.jar and y.jar use version
> 1.0, while z.jar use version 2.0.
>
> So, when I create a ClassLoader by saying:
> ClassLoader treeClassLoader = TreeClassLoaders.makeClassLoader(new File("lib"));
>
> The class loader will honor the tree structure and enforce precedence.
>
> I feel this way I can manage dependencies naturally in directories
> without explicitly specifying versions as in maven.
>
> Ben.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Problem in extending org.apache.tools.ant.taskdefs.Java class
Posted by Ben <aj...@gmail.com>.
Suppose I have a directory tree
/lib
/framework1
a-1.0.jar
x.jar
y.jar
/framework2
z.jar
a-2.0.jar
a-1.0.jar and a-2.0.jar are different versions of the same library.
A tree class loader will make sure that x.jar and y.jar use version
1.0, while z.jar use version 2.0.
So, when I create a ClassLoader by saying:
ClassLoader treeClassLoader = TreeClassLoaders.makeClassLoader(new File("lib"));
The class loader will honor the tree structure and enforce precedence.
I feel this way I can manage dependencies naturally in directories
without explicitly specifying versions as in maven.
Ben.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Problem in extending org.apache.tools.ant.taskdefs.Java class
Posted by Antoine Levy-Lambert <an...@gmx.de>.
Hello Ben,
what is a tree class loader ?
Regards,
Antoine
Ben wrote:
> Nah. commandline will never get me the hierarchy that I want. java.exe
> only accepts a flat set of urls.
>
> What I'm doing is to have a proxy class: MainProxy.
>
> 1. A system property will be set (say, set it to "lib") to call MainProxy
> 2. Another system property is set to the actually class name.
> 3. when MainProxy takes controll from within the new vm, it reads the
> class path tree property (which is "lib" in this case).
> 4. MainProxy creates a tree class loader that looks recursively into
> all jars under lib.
> 5. MainProxy loads the target class using the tree class loader.
> 6. MainProxy also needs to set the thread context class loader.
>
> And there it goes.
>
> It's just the commons-logging thing always giving me problem. Had to
> do ugly work-around for it.
>
> :-(
>
>
>
>
>
> On 8/8/06, Stefan Bodewig <bo...@apache.org> wrote:
>> On Mon, 7 Aug 2006, Ben <aj...@gmail.com> wrote:
>>
>> > I'm talking about the forked version, cuz that's almost the only
>> > mode I use. :-)
>>
>> How do you get your classloader into the forked VM? What kind of
>> changes do you need to make to the task? Only modify the commandline
>> used to start the VM?
>>
>> Stefan
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Problem in extending org.apache.tools.ant.taskdefs.Java class
Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 8 Aug 2006, Ben <aj...@gmail.com> wrote:
> On 8/8/06, Stefan Bodewig <bo...@apache.org> wrote:
>
>> So technically modifying the java task to allow your subclass to
>> control the CommandlineJava instance that's being used (in the same
>> way the JUnit task does) should work. Correct?
>>
>
> Looks not that easy. JUnit task exclusively uses getCommandLine()
> method to get the CommandlineJava object, which gives me an
> extension point (well, based upon the impl detail though).
>
> Java task uses "cmdl" variable directly, there's no way I can sneak
> anything in there. So, I'm still stuck. :-<
Note that I talked about modifying the Java task. It would be doable
(and in fact I'll just do it in a few minutes) to modify the task so
that it behaves the same way as the JUnit task does WRT the
CommandlineJava instance. I was just checking whether this would be
enough for the extensions you have in mind.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Problem in extending org.apache.tools.ant.taskdefs.Java class
Posted by Ben <aj...@gmail.com>.
Looks not that easy. JUnit task exclusively uses getCommandLine()
method to get the CommandlineJava object, which gives me an extension
point (well, based upon the impl detail though).
Java task uses "cmdl" variable directly, there's no way I can sneak
anything in there. So, I'm still stuck. :-<
On 8/8/06, Stefan Bodewig <bo...@apache.org> wrote:
> On Tue, 8 Aug 2006, Ben <aj...@gmail.com> wrote:
>
> > Nah. commandline will never get me the hierarchy that I
> > want. java.exe only accepts a flat set of urls.
>
> I know. That's why I assumed you only needed to modify the non-forked
> case.
>
> > What I'm doing is to have a proxy class: MainProxy.
>
> So still you only need to modify the command line. Add two system
> properties, remove the classpath setting and throw in MainProxy as the
> class to execute.
>
> So technically modifying the java task to allow your subclass to
> control the CommandlineJava instance that's being used (in the same
> way the JUnit task does) should work. Correct?
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Problem in extending org.apache.tools.ant.taskdefs.Java class
Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 8 Aug 2006, Ben <aj...@gmail.com> wrote:
> Nah. commandline will never get me the hierarchy that I
> want. java.exe only accepts a flat set of urls.
I know. That's why I assumed you only needed to modify the non-forked
case.
> What I'm doing is to have a proxy class: MainProxy.
So still you only need to modify the command line. Add two system
properties, remove the classpath setting and throw in MainProxy as the
class to execute.
So technically modifying the java task to allow your subclass to
control the CommandlineJava instance that's being used (in the same
way the JUnit task does) should work. Correct?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Problem in extending org.apache.tools.ant.taskdefs.Java class
Posted by Ben <aj...@gmail.com>.
Nah. commandline will never get me the hierarchy that I want. java.exe
only accepts a flat set of urls.
What I'm doing is to have a proxy class: MainProxy.
1. A system property will be set (say, set it to "lib") to call MainProxy
2. Another system property is set to the actually class name.
3. when MainProxy takes controll from within the new vm, it reads the
class path tree property (which is "lib" in this case).
4. MainProxy creates a tree class loader that looks recursively into
all jars under lib.
5. MainProxy loads the target class using the tree class loader.
6. MainProxy also needs to set the thread context class loader.
And there it goes.
It's just the commons-logging thing always giving me problem. Had to
do ugly work-around for it.
:-(
On 8/8/06, Stefan Bodewig <bo...@apache.org> wrote:
> On Mon, 7 Aug 2006, Ben <aj...@gmail.com> wrote:
>
> > I'm talking about the forked version, cuz that's almost the only
> > mode I use. :-)
>
> How do you get your classloader into the forked VM? What kind of
> changes do you need to make to the task? Only modify the commandline
> used to start the VM?
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Problem in extending org.apache.tools.ant.taskdefs.Java class
Posted by Stefan Bodewig <bo...@apache.org>.
On Mon, 7 Aug 2006, Ben <aj...@gmail.com> wrote:
> I'm talking about the forked version, cuz that's almost the only
> mode I use. :-)
How do you get your classloader into the forked VM? What kind of
changes do you need to make to the task? Only modify the commandline
used to start the VM?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Problem in extending org.apache.tools.ant.taskdefs.Java class
Posted by Ben <aj...@gmail.com>.
Stephan,
I'm talking about the forked version, cuz that's almost the only mode I use. :-)
Will verify the new JUnitTask once I'm through the test. (been having
a bit problem with libs using commons logging.)
Ben.
On 8/7/06, Stefan Bodewig <bo...@apache.org> wrote:
> On Mon, 7 Aug 2006, Ben <aj...@gmail.com> wrote:
>
> > I hope this is the right place for me to ask development quesiton
> > about Ant.
>
> It is. This is the list where development of Ant itself is discussed
> and what you want might require a change to Ant, so you meet the right
> people here.
>
> > Now I'm trying to create my own "java" task and "junit" task to
> > utilize this class loader.
>
> We are talking about the non-forked execution of tha java and junit
> tasks only, right?
>
> > One problem I'm facing here is, I cannot seem to be able to extend
> > org.apache.tools.ant.taskdefs.Java class to do what I want to do.
>
> Many if not most tasks haven't been written with extension in mind,
> I'm not surprised that you don't find a clean extension point.
>
> > The executeJava() has quite long logic that I want to re-use. But I
> > can't seem to find an extension point to make use of my class
> > loader.
>
> [I'm talking about Ant's svn trunk version since we'd only make
> changes there anyway]
>
> Since we are only talking about the non-forked version, you'd probably
> rather override run(CommandlineJava) - which is private - or somehow
> make the task use a subclass of ExcecuteJava of yours. ExecuteJava
> creates an AntClassLoader internally, so you probably need to modify
> it yourself.
>
> I see options of making run() protected or factor out the line
>
> ExecuteJava exe = new ExecuteJava();
>
> into a protected method that you could override. I'd prefer the
> second version.
>
> > There's similar problem with the JUnitTask class. But seems there's
> > a spot that I can hack in my logic. (to override the
> > getCommandline() method)
>
> Please check whether it still works with Ant's current svn trunk
> version since Ant 1.7.0 using that code is coming around pretty soon.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Problem in extending org.apache.tools.ant.taskdefs.Java class
Posted by Stefan Bodewig <bo...@apache.org>.
On Mon, 7 Aug 2006, Ben <aj...@gmail.com> wrote:
> I hope this is the right place for me to ask development quesiton
> about Ant.
It is. This is the list where development of Ant itself is discussed
and what you want might require a change to Ant, so you meet the right
people here.
> Now I'm trying to create my own "java" task and "junit" task to
> utilize this class loader.
We are talking about the non-forked execution of tha java and junit
tasks only, right?
> One problem I'm facing here is, I cannot seem to be able to extend
> org.apache.tools.ant.taskdefs.Java class to do what I want to do.
Many if not most tasks haven't been written with extension in mind,
I'm not surprised that you don't find a clean extension point.
> The executeJava() has quite long logic that I want to re-use. But I
> can't seem to find an extension point to make use of my class
> loader.
[I'm talking about Ant's svn trunk version since we'd only make
changes there anyway]
Since we are only talking about the non-forked version, you'd probably
rather override run(CommandlineJava) - which is private - or somehow
make the task use a subclass of ExcecuteJava of yours. ExecuteJava
creates an AntClassLoader internally, so you probably need to modify
it yourself.
I see options of making run() protected or factor out the line
ExecuteJava exe = new ExecuteJava();
into a protected method that you could override. I'd prefer the
second version.
> There's similar problem with the JUnitTask class. But seems there's
> a spot that I can hack in my logic. (to override the
> getCommandline() method)
Please check whether it still works with Ant's current svn trunk
version since Ant 1.7.0 using that code is coming around pretty soon.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org