Ah ok. Thanks Stefan for the clarification. Is that the way we want Ant to operate ? Don't you think it would be better if the "reverseloader" mode was the default one. It would be backward compatible in all cases except for persons like who were counting on their classpath was being picked before the system classpath.
I do agree, it is not nice to have my jar in both places. It wasn't actually meant that way. I had just dropped my cactus-ant.jar in anthome/lib a long time ago for some quick test I did ... and had forgotten about it ... until 3 months later I had to change one task ... I think it is safer to load the user classpath before the system classpath, making the user classloader a child of the system classloader. What do you think ? Thanks -Vincent > -----Original Message----- > From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > Sent: 28 February 2002 09:31 > To: [EMAIL PROTECTED] > Subject: Re: Custom Ant tasks and classpath issue > > On Wed, 27 Feb 2002, Vincent Massol <[EMAIL PROTECTED]> wrote: > > > I have just discovered today that Ant seems to put java.class.path > > by default in the task classpath. Thus, the second pathelement entry > > is actually not needed. > > Hmm, no, not really. > > Ant uses a delegating class loader, i.e. it will ask the system > classloader to load your task before even looking at the classpath you > have specified (and that's the reason why the build.sysclasspath > setting doesn't change anything). > > <taskdef> has an undocumented and deprecated reverseloader attribute > that would make Ant consult the classpath you have specified before it > asks the system classloader. > > Stefan > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
