| Summary: | Problems specific to OpenVMS | ||
|---|---|---|---|
| Product: | Ant | Reporter: | Meg Garrison <Meg.watson> |
| Component: | Core | Assignee: | Ant Notifications List <notifications> |
| Status: | NEW --- | ||
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 1.7.0 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | other | ||
| Attachments: |
Log file from ant junit test run against latest cvs sources
OpenVMS test run results against 1.7 from 11-Oct CVS source |
||
|
Description
Meg Garrison
2004-10-07 20:03:39 UTC
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! |