Hi, I'm attaching the log of a recent junit test suite run against the latest Ant CVS (1.7 Alpha) checkout. We're happy to help fix some of these problems as well as we can. The JVM on OpenVMS has some oddities. We haven't tried to fix anything except the java task. We made a patch for the problems (failures) in Javatest; we needed that to work for NetBeans 4.0 support on OpenVMS. With our fix, we now see no failures of the Javatest and 5 errors. Previously (as this attachment shows) there were 24 tests run, 3 failures and 5 errors. I'm sure there are probably some obvious things you can tell me to do to get a better success rate on openvms. I'm open to your suggestions. Thanks for your help, Meg Garrison Hewlett-Packard OpenVMS Engineering
Created attachment 12986 [details] Log file from ant junit test run against latest cvs sources
A lot of these seem to have an underlying cause; file system differences. For example, lots of tests fail as an expected file isn't where we expect it. We also seem to get different return codes from forked java programs, which may be related to either the way VMS does returns differently, <touch> doesnt set dates: [junit] Testcase: testMillis(org.apache.tools.ant.taskdefs.TouchTest): FAILED [junit] Time 662256000000 is not within 1000 ms of 3813679200000 [junit] junit.framework.AssertionFailedError: Time 662256000000 is not within 1000 ms of 3813679200000 [junit] at junit.framework.Assert.fail(Assert.java) [junit] at junit.framework.Assert.assertTrue(Assert.java) [junit] at org.apache.tools.ant.taskdefs.TouchTest.assertTimesNearlyMatch(TouchTest.java) This looks like File.touch() doesn't work, as whenever Ant tries to put the clock back on a file, we get a failure. Is this a known feature of the VMS JVM? The other file system test that fails everywhere is File.isDirectory(). A lot of tests verify that directories are not valid sources, and this isnt being picked up. Again, is this a known VMS quirk?
Yes, file system differences could certainly account for the majority of the test failures. Touchtests: Hmm, I'll have to look into this a little deeper. exec() return codes: On VMS, success is odd, usually 1, but odd nonetheless, and failure is even. I'll check with the JVM folks and see if there is some kind of logical name we can specify to tell the JVM to behave differently. isDirectory: isDirectory does indeed work on OpenVMS. However, on VMS the directory is a file named "somefoldername.DIR" (case of the extension is important, BTW), so if there is a file in the same directory as "somefoldername.DIR" with the name "somefoldername" (no extension), then when the call is made to File.isDirectory(new File("/a/b/c/somefoldername")), false is returned. I suspect that is what is happening. Note that if there is no file named "somefoldername" (no extension) then File.isDirectory(new File ("/a/b/c/somefoldername") will return true. More on touch and exec a little later today.
>>This looks like File.touch() doesn't work, as whenever Ant tries to put the >>clock back on a file, we get a failure. Is this a known feature of the VMS >>JVM? What is File.touch()? Not part of Java is it?
At the moment, it looks like File.setLastModified() is not working correctly on VMS. I am in contact with the JVM team and will post more information as I have it.
Turns out to be a VMS JVM bug in their file information cacheing algorithm. I have a switch to use to turn it off and am re-running the tests now.
Created attachment 13098 [details] OpenVMS test run results against 1.7 from 11-Oct CVS source
Looking at this... if JUnitTaskTest fails, then in theory no other test even matters. :) So I'd say that would be the first to get working!