Wannheden, Knut wrote:
What remains to be done: 1. Add a method Execute#isFailure(int result) or something similar 1.1 Modify <exec> to use this method 1.2 Update documentation of <exec> 2. Write a RUNANT.COM DCL sript for shell execution 3. Write a ANT.COM (and BUILD.COM) script
Task 1. (and 1.1, 1.2) should be easy.
2. could prove to be pretty hard as Java would actually
pass a Unix style
path to the DCL script which would have to be parsed into a
VMS filespec.
unless java does the VMS filespec generation
That's another possibility. But in that case the VMS specific code wouldn't only be inside oat.ant.taskdefs.Execute, but also in <exec> and <arg>. Worse yet, this translation isn't really trivial either. The JVM has to do it somewhere, but that function isn't exposed for reuse inside Java.
Is its location known for reflection abuse? Otherwise we reimplement it in FileUtils...the latter gives one the option of generating VMS paths in ant for other purposes.
I am much more strongly in favour of having the conversion code in java rather than in some string we pump out to a COM file. At the very least, it lets us have a junit test to verify the conversion works.
3. would be about to make Ant VMS compatible in general.
could you re-use the perl scripts?
You're talking about runant.pl to invoke Ant, right? Yes, that or also runant.py should work on VMS. I noted that the CVS HEAD of those still use oat.ant.Main instead of oat.ant.launch.Launcher, as ant.bat and ant do.
time for an update. Ant on netware uses the perl script BTW, and with the fewer lauchers we have, the easier it is to support.
But there's no build.pl and bootstrap.pl, but I supose it's not really necessary to be able to build Ant on VMS.
Not unless you want to run the nightly gump on VMS...
-- knut
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
