Stefan, thanks for the answer,
> > Note the '\' prefixing the name as it is a specific case of the > > Shouldn't that be a forward slash? my mistake. > > So I guess it is a problem in Ant. I though it was a classLoader > > problem. > > I think it is. If so I can perhaps help to debug it? So I should run it in -debug mode, isn't it? Is there a way to run ant with the jdb instead of java? > The getResource methods have not been implemented in Ant 1.3, but they > are supposed to work in the nightly builds. Maybe the implementation > is not working correctly in all cases. I am using now 1.4 alpha from the 05th. Same problem. I should perhaps try to make a testcase. This bug - as it seems now - is painful to me. I am converting this project to Ant reuses Log4J. The project contains a wrapper class that loads the Log4J property file using this getResourceAsStream method. This fails with Ant but works otherwise. That's not practical. I will try to make a testcase but would be happy to know if other people experienced the same problems. > > I tried to fork the JVM and to force to pass the correct classpath > > by adding a sysproperty task before the junit one: > [snip] > > This didn't work. Forking the JVM fails because I then have to set > > JUnit in my classpath, thing that I don't want. > > Even if you don't want to do so, it would help to debug the current > situation. Please add junit.jar and optional.jar to your defined > classpath and run the task in forked mode. I do so now. It works but I had to modify my installation. It forces me to modify my ant script so it takes into account an external definition of the classpath, and I don't like it. I would prefer to only require ant installed (with the correct libraries). BTW I have an important question: I do put my third party libraries into the %ANT_HOME%\lib, so I only need to install it once per project. (I can see problems there if a project use a different version of the library installed with Ant. But otherwise?) Is this considered good or not?
