You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Jérôme Lacoste <je...@smartcardsystem.com> on 2001/07/05 19:29:26 UTC

Bug? JUnit and classpath problems. Ant classloader?

Me again :)

I have some strange problems with classpath and the JUnit task.
My code use the the getResourceAsStream(String filePath) method of the Class
class.

I pass it the following String: "\test_log.properties" (note: I do that in
fact to retrieve a stream of the property files for the Log4J tool version
0.9.4). Note the '\' prefixing the name as it is a specific case of the
Class method.
(http://www.java.sun.com/j2se/1.3/docs/api/java/lang/Class.html#getResourceA
sStream(java.lang.String).


When I run my code in JBuilder everything works. If I make a batch file as
well.
But when I execute it within a JUnit Ant task, it fails.

extract of my build.xml:

<target name="test.case" if="testcase" depends="compile.tests"
	description="Runs the specified JUnit test case">
	<junit printsummary="no" haltonfailure="${bvt.haltonfailure}">
		<classpath>
			<path refid="tests.classpath" />
		</classpath>
			<formatter type="plain" usefile="${bvt.formater.usefile}" />
			<test name="${testcase}" />
	</junit>
</target>


So I guess it is a problem in Ant. I though it was a classLoader problem. I
downloaded and installed the latest nightly version of Ant but the problem
is still there.

When I run Ant with -verbose, the JUnit tasks prints correctly the classpath
I am passing, but my code (running in the same JVM) does not print the
complete classpath (i.e. ${tests.classpath} as passed by the junit task) but
prints the one created by the ant.bat script.

I tried to fork the JVM and to force to pass the correct classpath by adding
a sysproperty task before the junit one:
<!-- classpath not passed !! -->
<property name="asd" refid="tests.classpath" />
<sysproperty key="java.class.path" value="${asd}"/>

This didn't work. Forking the JVM fails because I then have to set JUnit in
my classpath, thing that I don't want.


This bug currently prevents me to use Ant to run some of my JUnit tests. Any
idea?

I was thinking of a bug in AntClassLoader but didn't investigate.

Any idea?

Jerome

Re: Bug? JUnit and classpath problems. Ant classloader?

Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 6 Jul 2001, Jirtme Lacoste
<je...@smartcardsystem.com> wrote:

>> > 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?

Yes, but you'll have to use a version of AntClassLoader from today (I
even guess my changes won't appear in the very next nightly build) - I
have added some debug information to the getResource methods that are
supposed to be called.

> Is there a way to run ant with the jdb instead of java?

Never tried to do that, sorry.  Others?

> I should perhaps try to make a testcase.

That would be great.

> 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?

I wouldn't do so, because I like to know what's on my CLASSPATH
instead of having things appear there magically, you mileage may
differ.

Stefan

RE: Bug? JUnit and classpath problems. Ant classloader?

Posted by Jérôme Lacoste <je...@smartcardsystem.com>.
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?


Re: Bug? JUnit and classpath problems. Ant classloader?

Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 5 Jul 2001, Jérôme Lacoste
<je...@smartcardsystem.com> wrote:

> Note the '\' prefixing the name as it is a specific case of the

Shouldn't that be a forward slash?

> So I guess it is a problem in Ant. I though it was a classLoader
> problem.

I think it is.

> When I run Ant with -verbose, the JUnit tasks prints correctly the
> classpath I am passing, but my code (running in the same JVM) does
> not print the complete classpath (i.e. ${tests.classpath} as passed
> by the junit task) but prints the one created by the ant.bat script.

If you specify a nested classpath element, Ant will use a classloader
of its own, but not alter java.class.path - so you cannot see it
there.

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 tried to fork the JVM and to force to pass the correct classpath
> by adding a sysproperty task before the junit one:

No, all you need is to set the classpath like you did, don't fiddle
with the system properties.

> 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.

Stefan