On Fri, 2003-06-20 at 06:23, Costin Manolache wrote:
> Nick Chalko wrote:
>
> > After I slept on it, I thought of how I could extend the antclassloader
> > to handle the situations I need.
> > I am considering a
> > That will explicitly allow the optional ant task to be loaded in the
> > child c
Costin Manolache wrote:
The part that loads junit.jar to the main loader is complete.
There are other possible enhancements to create arbitrary loaders
or support reloading which are not yet implemented.
That still failed for me.
I tried this
Fails with
$ ant
Build
Nick Chalko wrote:
> After I slept on it, I thought of how I could extend the antclassloader
> to handle the situations I need.
> I am considering a
> That will explicitly allow the optional ant task to be loaded in the
> child classloader.
> I may even go so far as automatically adding this fi
Conor MacNeill wrote:
>> >BTW, I don;t really agree with the task being used to
>> >modify
>> > the effective classpath of running ClassLoaders. I'm sure this will
>> > cause trouble too.
>>
>> Seems to break some of the "properties are immutable" philosophy of ant.
>
> No - not really an Ant
It might appear to work but can fail in subtle ways. I have had instances
where the second invocation of a task would cause an error because it would
bring classes into the VM which were there already leading to two different
class instances with the same classname being reachable (loader const
On Fri, 20 Jun 2003 01:40 am, Nick Chalko wrote:
>
> The
> if (resourceName.startsWith("org.apache.tools.ant.taskdefs.optional."))
> {return useParentFirst;}
> HACK worked last night.
>
> I will try something a little cleaner tonight.
It might appear to work but can fail in subtle ways. I have had
Conor MacNeill wrote:
On Fri, 20 Jun 2003 12:17 am, Nick Chalko wrote:
I'll be interested to see if this works :-) I have my doubts. As soon as you
go into the main loader to find the task classes
(org.apache.tools.ant.taskdefs.optional.junit.JUnitTask), you won't be able
to see the Juni
On Fri, 20 Jun 2003 12:17 am, Nick Chalko wrote:
> After I slept on it, I thought of how I could extend the antclassloader
> to handle the situations I need.
> I am considering a
> That will explicitly allow the optional ant task to be loaded in the
> child classloader.
> I may even go so far as
After I slept on it, I thought of how I could extend the antclassloader
to handle the situations I need.
I am considering a
That will explicitly allow the optional ant task to be loaded in the
child classloader.
I may even go so far as automatically adding this fileset
${ant.home}/lib/ant-*
Ah, I see.
That would be nice, but the classloader task is not
yet complete.
Peter
On Thu, 2003-06-19 at 08:52, Nick Chalko wrote:
> peter reilly wrote:
>
> >Check the ant faq http://ant.apache.org/faq.html#delegating-classloader
> >In essence you need to place the junit.jar file in ${ant.home}/
peter reilly wrote:
Check the ant faq http://ant.apache.org/faq.html#delegating-classloader
In essence you need to place the junit.jar file in ${ant.home}/lib
I had hoped that was what the task would let me avoid.
smime.p7s
Description: S/MIME Cryptographic Signature
Check the ant faq http://ant.apache.org/faq.html#delegating-classloader
In essence you need to place the junit.jar file in ${ant.home}/lib
Cheers,
Peter
On Thu, 2003-06-19 at 08:43, Nick Chalko wrote:
>
>
>
>
>
>
>
>
> classname="org.apache.tools.ant.taskd
Btw
I can make this work if I include junit.jar and ant-junit.jar in the path.
And hack AntClassloader.
private boolean isParentFirst(String resourceName) {
// default to the global setting and then see
// if this class belongs to a package which has been
// designated to u
Fails with
$ ant
Buildfile: build.xml
BUILD FAILED
C:\tools\ant-head\tools\antlibs\junit-0.1.1-dev-20030618.antlib\build.xml:12:
ta
skdef: A class needed by class
org.apache.tools.ant.taskdefs.optional.junit.JUni
tTask cannot be found: junit/framework/TestListe
14 matches
Mail list logo
