ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Reilly" <peter.kitt.rei...@gmail.com>
Subject Re: Did 1.7RC1 break JUnit 4.x compatibility?
Date Wed, 15 Nov 2006 15:21:28 GMT
On 11/15/06, Steve Loughran <stevel@apache.org> wrote:
> Stan Guillory wrote:
> > Well, rebooting a Solaris box isn't an option. :*)
> >
> > So here is what I have tried:
> >
> > 1) Used the tempdir attribute to create temporary files in /tmp instead
> > of the basedir of the project. This did not help. Got the same errors.
> >
> > 2) Copied my entire source tree out of the vob to a local file system
> > and built there. Same problem. Here is the stack trace I am getting on
> > every unit test:
> >
> >     [junit] java.io.FileNotFoundException:
> > /tmp/junitvmwatcher735044513.properties (No such file or directory)
> >     [junit]     at java.io.FileInputStream.open(Native Method)
> >     [junit]     at
> > java.io.FileInputStream.<init>(FileInputStream.java:106)
> >     [junit]     at java.io.FileReader.<init>(FileReader.java:55)
> >     [junit]     at
> > org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeAsForked(J
> > UnitTask.java:1025)
> >     [junit]     at
> > org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask
> > .java:817)
> >     [junit]     at
> > org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeOrQueue(JU
> > nitTask.java:1627)
> >     [junit]     at
> > org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask
> > .java:764)
> >     [junit]     at
> > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
> >     [junit]     at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown
> > Source)
> >     [junit]     at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
> > Impl.java:25)
> >     [junit]     at java.lang.reflect.Method.invoke(Method.java:585)
> >     [junit]     at
> > org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:1
> > 05)
> >     [junit]     at org.apache.tools.ant.Task.perform(Task.java:342)
> >     [junit]     at org.apache.tools.ant.Target.execute(Target.java:357)
> >     [junit]     at
> > org.apache.tools.ant.Target.performTasks(Target.java:385)
> >     [junit]     at
> > org.apache.tools.ant.Project.executeSortedTargets(Project.java:1292)
> >     [junit]     at
> > org.apache.tools.ant.Project.executeTarget(Project.java:1261)
> >     [junit]     at
> > org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecut
> > or.java:41)
> >     [junit]     at
> > org.apache.tools.ant.Project.executeTargets(Project.java:1144)
> >     [junit]     at org.apache.tools.ant.Main.runBuild(Main.java:698)
> >     [junit]     at org.apache.tools.ant.Main.startAnt(Main.java:199)
> >     [junit]     at
> > org.apache.tools.ant.launch.Launcher.run(Launcher.java:298)
> >     [junit]     at
> > org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)
> >     [junit] Running com.swacorp.ecustomer.hotels.http.hotelPreCancelTest
> >     [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0 sec
> >     [junit] Test com.swacorp.ecustomer.hotels.http.hotelPreCancelTest
> > FAILED (crashed)
> >
> >
> > So basically all I can say at this point is that the junit4 support in
> > 1.7RC1 works with a trivial example, but is not working on Windows or
> > Solaris with a more typical project. I will revert to ant 1.6.5 for not
> > until I can try to reproduce this issue at home.
>
> Well, the good news is that we know its not a Clearcase problem. That is
> progress, and means its a problem we can probably fix. Maybe its a race
> condition. If we can't replicate it we may have to cut a copy for you
> with extra diagnostics/delays in (like do a listing of the temp dir when
> we cannot open the file). Actually, handling a filenotfoundexception at
> this point is something to consider having better handling/diagnostics
> for in any situation.

Looking at the code, the following could have happened:
In JUnitTest, the vmwatcher file name is created (no file
is written).
The JUnitTestRunner class is executes in a new vm, it fails before
it processess all the arguments, i.e. before processing the CRASHFILE
arguement, which creates the vmwatcher file and writes info to it.
The "finally" part of JUnitTest#nexecuteAsForked is run, it
does not check if the vmwatcher file is present before opening
it.

So there is two problems here:
 1) JUnitTestRunner cannot be run (cannot load class ?), or it only
runs for a small time
     (commandline args are messed up ?)
 2) error handling in JUnitTest#executeAsForked is wonky.

2) can be solved easily
For 1) we need more information.
- try to reduce to the smallest set of files that show the problem.

Peter

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


Mime
View raw message