> >>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
> and .
> > Worse yet, this translation isn't really trivial either.
> The JVM has to do
>
Wannheden, Knut wrote:
What remains to be done:
1. Add a method Execute#isFailure(int result) or something similar
1.1 Modify to use this method
1.2 Update documentation of
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
On Fri, 25 Jul 2003, Knut Wannheden <[EMAIL PROTECTED]> wrote:
> That's right. But it can't be fixed in Execute, as Execute only
> deals with the command as a String array.
True.
> It would have to be done a level up. So either a VMS specific
> is needed or the tasks, like , need to be OS awa
>
> The way it is now will make useless on OpenVMS, right? The
> code now expects file names to be in OpenVMS format while is
> going to add any source/target files in Unix format.
>
That's right. But it can't be fixed in Execute, as Execute only deals with
the command as a String array. It
On Thu, 24 Jul 2003, Knut Wannheden <[EMAIL PROTECTED]> wrote:
> 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.
The way it is now will make useless on OpenVMS, right? The
code now expects fi
Hi,
I have now written a simple patch for the task to make it OpenVMS
compatible. I've added it to Bugzilla (ID 21877).
The Execute class now has an OpenVMS specific CommandLauncher which writes
the command into a temporary DCL script. Further a static method
Execute#isFailure(int exitValue) i
> >
> > What remains to be done:
> > 1. Add a method Execute#isFailure(int result) or something similar
> > 1.1 Modify to use this method
> > 1.2 Update documentation of
> > 2. Write a RUNANT.COM DCL sript for shell execution
> > 3. Write a ANT.COM (and BUILD.COM) script
> >
> > Task 1. (a
Wannheden, Knut wrote:
If I'm not mistaken then a DCL script can only process a maximum of
8 arguments and the call to a DCL script from Java, including the
script filename and its arguments, can at the most be 256 characters
long.
I'm out of OpenVMs business for too long, to know whether you are
c
>
> > If I'm not mistaken then a DCL script can only process a maximum of
> > 8 arguments and the call to a DCL script from Java, including the
> > script filename and its arguments, can at the most be 256 characters
> > long.
>
> I'm out of OpenVMs business for too long, to know whether you are
Steve,
>
> Maybe we could start with a run of the full ant unit test
> suite on VMS
> to see what happens.
>
That souds like a good idea. I will try to do that. But I can only run the
tests on the system I have access to, which is OpenVMS 7.3.1 for Alpha with
HP's JVM version 1.4.1. I'll l
Ken Gentle wrote:
Guys, if you're willing to introduce a JNI lib for VMS, all the
operations you wish to perform are available through VMS System
Services, including getting/setting the Logical Names, and, IIRC,
launching a DCL interpreter directly, avoiding the need for the DCL
wrapper.
It's
On Thu, 10 Jul 2003, Knut Wannheden <[EMAIL PROTECTED]> wrote:
> If I'm not mistaken then a DCL script can only process a maximum of
> 8 arguments and the call to a DCL script from Java, including the
> script filename and its arguments, can at the most be 256 characters
> long.
I'm out of OpenVM
On Thu, 10 Jul 2003, Gus Heck <[EMAIL PROTECTED]> wrote:
> So I read this and looked to my left at the Design Patterns book
> that was already open to the Adapter Pattern for other reasons...
We already sort-of use it for the CommandLauncher, I'd decide on a
case by case basis whether an if or a
On Thu, 10 Jul 2003, Knut Wannheden <[EMAIL PROTECTED]> wrote:
>> So let's really treat OpenVMS like OS/2 and disable the
>> Jdk13Launcher unconditionally.
>
> The Java CommandLauncher for VMS could catch the IOException with
> the message "function not implemented" and tell the user to define
>
- The Ant task throws a BuildException if the exit code
is unequal zero.
Do you know how to get around that? Should the Execute class, in
the case of VMS, map the exit status to what's common on Unix
systems?
Maybe we should provide a Execute.isFailure(int result) method that
returns result !
>
> > But the other Runtime.exec() methods (without working directory)
> > should all work.
>
> So let's really treat OpenVMS like OS/2 and disable the Jdk13Launcher
> unconditionally.
>
The Java CommandLauncher for VMS could catch the IOException with the
message "function not implemented" and
On the 8 argument limitation, you could pass *all* the arguments in a
single DCL argument, then have the wrapper parse them (DCL has some
reasonable tokenizing functions IIRC)
I don't recall any restriction on the size of DCL script arguments, but it
will documented be in the DCL manual.
At 11
> At the moment it seems that Ant's basic requirements to make
> work could be covered by Java and maybe an ANTRUN.COM DCL script along
> the lines of antRun and antrun.bat.
>
If I'm not mistaken then a DCL script can only process a maximum of 8
arguments and the call to a DCL script from Java,
On Thu, 10 Jul 2003, Ken Gentle <[EMAIL PROTECTED]> wrote:
> At 10:45 AM 7/10/2003, you wrote:
>>On Thu, 10 Jul 2003, Ken Gentle <[EMAIL PROTECTED]> wrote:
>>
>> > Guys, if you're willing to introduce a JNI lib for VMS, all the
>> > operations you wish to perform are available through VMS System
>>
At 10:45 AM 7/10/2003, you wrote:
On Thu, 10 Jul 2003, Ken Gentle <[EMAIL PROTECTED]> wrote:
> Guys, if you're willing to introduce a JNI lib for VMS, all the
> operations you wish to perform are available through VMS System
> Services,
Sure - just like many useful Unix operations (like stat or set
On Thu, 10 Jul 2003, Ken Gentle <[EMAIL PROTECTED]> wrote:
> Guys, if you're willing to introduce a JNI lib for VMS, all the
> operations you wish to perform are available through VMS System
> Services,
Sure - just like many useful Unix operations (like stat or setuid)
could be 8-)
At the moment
On Thu, 10 Jul 2003, Knut Wannheden <[EMAIL PROTECTED]> wrote:
> But the other Runtime.exec() methods (without working directory)
> should all work.
So let's really treat OpenVMS like OS/2 and disable the Jdk13Launcher
unconditionally.
> There seem to be some other tasks which check the return v
Guys, if you're willing to introduce a JNI lib for VMS, all the operations
you wish to perform are available through VMS System Services, including
getting/setting the Logical Names, and, IIRC, launching a DCL interpreter
directly, avoiding the need for the DCL wrapper.
It's been a while (like
Stefan,
>
> > I think it should all be solvable inside Execute. You could
> > restrict users to only execute .EXE and .COM files on VMS. Another
> > solution is to write the command to a temporary .COM and then
> > execute that. But I have to do some more testing here.
>
> In either case, we
On Thu, 10 Jul 2003, Knut Wannheden <[EMAIL PROTECTED]> wrote:
> The VM supports both VMS native file path syntax and a Unix style
> filenames for most operations.
I see.
> These limitations are imposed by the VM implementation. In summary
> you can run .EXE images using Unix style filenames an
Stefan,
Thanks for your quick reply.
>
> > At our company we're developing Ada95 code for various platforms,
> > including OpenVMS.
>
> You are the first person reporting anything about Ant on OpenVMS
> AFAIK.
>
Don't know whether I should be surprised or not... But the VM
implementation pro
On Thu, 10 Jul 2003, Knut Wannheden <[EMAIL PROTECTED]> wrote:
> At our company we're developing Ada95 code for various platforms,
> including OpenVMS.
You are the first person reporting anything about Ant on OpenVMS
AFAIK.
I used to work with OpenVMS about seven to five years ago, but I've
neve
27 matches
Mail list logo
