You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by st...@apache.org on 2006/05/09 22:25:51 UTC
svn commit: r405524 - in /ant/core/trunk/src:
main/org/apache/tools/ant/taskdefs/Execute.java
main/org/apache/tools/ant/taskdefs/rmic/ForkingSunRmic.java
testcases/org/apache/tools/ant/taskdefs/ExecuteWatchdogTest.java
Author: stevel
Date: Tue May 9 13:25:48 2006
New Revision: 405524
URL: http://svn.apache.org/viewcvs?rev=405524&view=rev
Log:
Adding a new non-static method, isFailure() to Execute. As well as simplifying a common operation, it is a foundation for instance specific logic to decide if an execute failed, which could be of use in VMS land.
Modified:
ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Execute.java
ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/rmic/ForkingSunRmic.java
ant/core/trunk/src/testcases/org/apache/tools/ant/taskdefs/ExecuteWatchdogTest.java
Modified: ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Execute.java
URL: http://svn.apache.org/viewcvs/ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Execute.java?rev=405524&r1=405523&r2=405524&view=diff
==============================================================================
--- ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Execute.java (original)
+++ ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Execute.java Tue May 9 13:25:48 2006
@@ -47,7 +47,9 @@
*/
public class Execute {
- /** Invalid exit code. **/
+ /** Invalid exit code.
+ * set to {@link Integer#MAX_VALUE}
+ */
public static final int INVALID = Integer.MAX_VALUE;
private static final FileUtils FILE_UTILS = FileUtils.getFileUtils();
@@ -584,6 +586,16 @@
// for other platforms nonzero exit value signals failure
return Os.isFamily("openvms")
? (exitValue % 2 == 0) : (exitValue != 0);
+ }
+
+ /**
+ * Did this execute return in a failure.
+ * @see #isFailure(int)
+ * @return true if and only if the exit code is interpreted as a failure
+ * @since Ant1.7
+ */
+ public boolean isFailure() {
+ return isFailure(getExitValue());
}
/**
Modified: ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/rmic/ForkingSunRmic.java
URL: http://svn.apache.org/viewcvs/ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/rmic/ForkingSunRmic.java?rev=405524&r1=405523&r2=405524&view=diff
==============================================================================
--- ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/rmic/ForkingSunRmic.java (original)
+++ ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/rmic/ForkingSunRmic.java Tue May 9 13:25:48 2006
@@ -65,9 +65,8 @@
exe.setAntRun(project);
exe.setWorkingDirectory(project.getBaseDir());
exe.setCommandline(args);
-
exe.execute();
- return exe.getExitValue() == 0;
+ return !exe.isFailure();
} catch (IOException exception) {
throw new BuildException("Error running " + SunRmic.RMIC_EXECUTABLE
+ " -maybe it is not on the path", exception);
Modified: ant/core/trunk/src/testcases/org/apache/tools/ant/taskdefs/ExecuteWatchdogTest.java
URL: http://svn.apache.org/viewcvs/ant/core/trunk/src/testcases/org/apache/tools/ant/taskdefs/ExecuteWatchdogTest.java?rev=405524&r1=405523&r2=405524&view=diff
==============================================================================
--- ant/core/trunk/src/testcases/org/apache/tools/ant/taskdefs/ExecuteWatchdogTest.java (original)
+++ ant/core/trunk/src/testcases/org/apache/tools/ant/taskdefs/ExecuteWatchdogTest.java Tue May 9 13:25:48 2006
@@ -27,12 +27,12 @@
*/
public class ExecuteWatchdogTest extends TestCase {
- private final static int TIME_OUT = 5000;
+ private final static long TIME_OUT = 5000;
private final static String TEST_CLASSPATH = getTestClassPath();
private final static int CLOCK_ERROR=200;
- private final static int TIME_OUT_TEST=TIME_OUT-CLOCK_ERROR;
+ private final static long TIME_OUT_TEST=TIME_OUT-CLOCK_ERROR;
private ExecuteWatchdog watchdog;
@@ -58,7 +58,7 @@
return classpath;
}
- private Process getProcess(int timetorun) throws Exception {
+ private Process getProcess(long timetorun) throws Exception {
String[] cmdArray = {
JavaEnvUtils.getJreExecutable("java"), "-classpath", TEST_CLASSPATH,
TimeProcess.class.getName(), String.valueOf(timetorun)
@@ -94,7 +94,7 @@
watchdog.start(process);
int retCode = waitForEnd(process);
assertTrue("process should not have been killed", !watchdog.killedProcess());
- assertEquals(0, retCode);
+ assertFalse(Execute.isFailure(retCode));
}
// test that the watchdog ends the process
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
RE: OpenVMS execution
Posted by "Hazzard, Powell" <Po...@hp.com>.
Steve Loughran:
>>If there are some executables with unix result code logic, and other
bits with VMS rules, then its essentially >>>impossible to
"automatically"
>>>make the right decision.
>>>We could switch to unix-policy-everywhere, with a per-<exec> flip to
VMS if you want run VMS-specific apps. My >>>concern there is cvs and
SVN: what kind of exe are they?
I'm not 100% but I think the cvs and SVN on OpenVMS are Java
implementations.
After spending several weeks fighting the JBOSS ant testsuite (on
OpenVMS) it is starting to feel as if we need to have an ANT default
(Unix success==0), then have a per-<exec> status code option that could
redefine the success. Or maybe an OpenVMS dcl task to handle true
"native" OpenVMS executables (Just a thought but I'm sure this is a
great idea).
Let's face it, most of the Ant environments of the world expect Unix
style status codes. To make matters worst your environment could be
distributed across different operating systems (svn or cvs for example).
I'm not sure I can answer the question "What is a success value in a
distributed environment?"
I can tell you this is why rmic (Java apps in general) on OpenVMS
still returns Unix style status codes. I guess instead of saying
"returns Unix style status code" I should say "returns Java style status
codes".
Recently, OpenVMS Java engineering has been asked to change Java
applications to return a more traditional OpenVMS status code, however
in the world of Java "Write once, run everywhere" development there is
not a "isFailure" method; thus Java on OpenVMS needs to continue to
return the same status code as Hp/UX, Solaris... so the same status
value means the same across platforms.
For example Javac has 5 different status codes:
http://www.cs.duke.edu/csed/java/src1.3/sun/tools/javac/Main.java
/**
* Exit status.
* We introduce a separate integer status variable, and do not
alter the
* convention that 'compile' returns a boolean true upon a
successful
* compilation with no errors. (JavaTest relies on this.)
*/
public static final int EXIT_OK = 0; // Compilation
completed with no errors.
public static final int EXIT_ERROR = 1; // Compilation
completed but reported errors.
public static final int EXIT_CMDERR = 2; // Bad command-line
arguments and/or switches.
public static final int EXIT_SYSERR = 3; // System error or
resource exhaustion.
public static final int EXIT_ABNORMAL = 4; // Compiler terminated
abnormally.
With the current isFailure method the values of EXIT_ERROR and
EXIT_SYSERR would be success.
Status codes are just the tip of the iceberg if we really want Ant to
internally support OpenVMS. The next area of concern could be the file
system. For example:
value="${env.JBOSS_HOME}/lib/ant.jar"/>
Internally Ant is expecting something like
"/usr/jboss/jboss-4.0.3sp1-src/lib/ant.jar
However the OpenVMS file system is a little bit different:
$ show log jboss_home
"JBOSS_HOME" = "swdisk:[JBOSS_src.jboss-4^.0^.3SP1-src.]"
(LNM$PROCESS_TABLE)
Resulting in "swdisk:[JBOSS_src.jboss-4^.0^.3SP1-src.]/lib/ant.jar"
Instead of Ant being asked to interpret VMS file syntax, it would be
best to have the VMS specific "env" return the correct Unix style
filename (which Java on OpenVMS understands).
Regards,
Powell
OpenVMS/Java engineering
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: OpenVMS execution
Posted by Stefan Bodewig <bo...@apache.org>.
On Mon, 15 May 2006, Powell Hazzard <Po...@hp.com> wrote:
> Stefan wrote:
>> I'd expect them to return EXIT_SUCCESS or EXIT_FAILURE which are
>> defined to be 1 and 0 respectively if I recall my OpenVMS C
>> knowledge correctly (which hasn't been used for eight years now).
>
> Your knowledge is still correct (You can compile with an option
> to flip EXIT_SUCCESS & EXIT_FAILURE on OpenVMS to honor normal
> OpenVMS status codes). However, Java really can't honor the
> EXIT_SUCCESS and EXIT_FAILURE flip in the traditional OpenVMS
> manner.
"them" in my sentence were cvs and svn which are written in C. I had
a quick look at the svn sources and indeed they use the macros defined
in stdlib.h. So svn should behave like a "real" OpenVMS executable.
For Java applications even Ant 1.6 expects it to behave Unix-like on
OpenVMS. If Ant knows it is executing Java (or a JDK executable) that
is. If you use <apply> to execute java.exe it won't work.
> As you can see I don't think internally Java can ever assume that it
> knows whether the final exit status is a success or failure value.
I don't think we can do so in any magic way, either. We can provide
reasonable defaults (which Ant 1.6 does IMHO) and make it overridable
on a task by task basis because only the build file author will know -
has a means to check.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
RE: OpenVMS execution
Posted by "Hazzard, Powell" <Po...@hp.com>.
Stefan wrote:
>>>... and break backwards compatibility with 1.6. I'd rather introduce
the flip but make it default to Ant 1.6's behavior.
I understand, hence we original suggested a property which flipped
the default behavior (Unix style or 1.6 behavior OpenVMS style). See:
http://issues.apache.org/bugzilla/show_bug.cgi?id=39359
>>>I'd expect them to return EXIT_SUCCESS or EXIT_FAILURE which are
defined to be 1 and 0 respectively if I recall my OpenVMS C knowledge
correctly (which hasn't been used for eight years now).
Your knowledge is still correct (You can compile with an option to
flip EXIT_SUCCESS & EXIT_FAILURE on OpenVMS to honor normal OpenVMS
status codes). However, Java really can't honor the EXIT_SUCCESS and
EXIT_FAILURE flip in the traditional OpenVMS manner. Why? As you know
Java application are interpret byte code until compiled at runtime; thus
we (OpenVMS Java) can not truly predict the application developer's
intention to change (or flip) the return value.
Better question EXIT_SUCCESS & EXIT_FAILURE are "C" compile-time
options on OpenVMS what should we do if we are using Ant's fork="false"
to run a task inline? Truly a 100% Java solution that does not touch
the native OS JVM code for returning an OS style status. Would this
mean if fork="true" we return the flipped status codes, if fork="false"
the isFailure() method knows we should be checking for Unix
style(0=success)?
We have to think of Java as a run-time library that allows 100% Java
applications to run on any platforms. Given this fact I don't foresee
anyway the Java run-time library can predict what is successful and what
a failure code is.
For example, in my last reply Javac has 5 different statuses, how you
would successfully map those results to any OpenVMS status code. And
then apply those same mappings/meanings for all Java applications.
Remember a Java application can be network connected across platforms
(Weblogic cluster servers don't have to all OpenVMS systems, they can be
Windows, HP/UX, and/or OpenVMS in the same cluster) you must be able to
have applications from any platform interpreter the status code in the
same manner.
Here are some other applications:
Javah has the following code:
0 Success
10 Fatal error
11 Bug needs to be reported
15 Usage error
Sun's Jck test suite returns a 95 for success, and 97 for failure.
Weblogic, Tomcat... all have a different set of status codes.
As you can see I don't think internally Java can ever assume that it
knows whether the final exit status is a success or failure value.
Regards,
Powell
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: OpenVMS execution
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 12 May 2006, Steve Loughran <st...@apache.org> wrote:
> Prior to ant1.6, the unix model was all that ant had. so it worked
> on all non -VMS platforms, and it worked for java apps
Correct, but as you say, this was prior to Ant 1.6.
> Then we put that patch from the OpenVMS people that said "here is
> the logic to handle VMS return codes", with some other stuff for
> execing java apps. I don't know where jdk exes fit in here - I think
> they need to be given unix rights.
And this is how Ant 1.6 has been treating it. Ant treated jdk
executables using the Unix model and only applied the OpenVMS logic
for the other executables.
> If there are some executables with unix result code logic, and other
> bits with VMS rules, then its essentially impossible to
> "automatically" make the right decision.
>
> We could switch to unix-policy-everywhere, with a per-<exec> flip to
> VMS if you want run VMS-specific apps.
... and break backwards compatibility with 1.6. I'd rather introduce
the flip but make it default to Ant 1.6's behavior.
> My concern there is cvs and SVN: what kind of exe are they?
I'd expect them to return EXIT_SUCCESS or EXIT_FAILURE which are
defined to be 1 and 0 respectively if I recall my OpenVMS C knowledge
correctly (which hasn't been used for eight years now).
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
OpenVMS execution
Posted by Steve Loughran <st...@apache.org>.
Stefan Bodewig wrote:
> On Thu, 11 May 2006, Steve Loughran <st...@apache.org> wrote:
>> Stefan Bodewig wrote:
>
>>> you also changed ForkingJavaRmic to use isFailure() instead of the
>>> exitCode == 0 check that was in it before. If rmic returns 0 on
>>> success on OpenVMS, you've just broken the task.
>> ooh, good point. Roll back?
>
> That's why I suggested you ask the people from your OpenVMS group -
> actually it would be good if at least one of them was subscribed here.
> Maybe you've fixed the task and not broken it.
I've been thinking about this whole thing. It comes down to this, (I
believe)
-classic VMS apps have a complex return code logic
-unix has a fairly simple 0 for success, !=0 for failure
-apps that ship with the JDK have the unix model
-java apps have the unix model
Prior to ant1.6, the unix model was all that ant had. so it worked on
all non -VMS platforms, and it worked for java apps
Then we put that patch from the OpenVMS people that said "here is the
logic to handle VMS return codes", with some other stuff for execing
java apps. I don't know where jdk exes fit in here - I think they need
to be given unix rights.
If there are some executables with unix result code logic, and other
bits with VMS rules, then its essentially impossible to "automatically"
make the right decision.
We could switch to unix-policy-everywhere, with a per-<exec> flip to VMS
if you want run VMS-specific apps. My concern there is cvs and SVN: what
kind of exe are they?
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: svn commit: r405524 - in /ant/core/trunk/src:
main/org/apache/tools/ant/taskdefs/Execute.java
main/org/apache/tools/ant/taskdefs/rmic/ForkingSunRmic.java
testcases/org/apache/tools/ant/taskdefs/ExecuteWatchdogTest.java
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 11 May 2006, Steve Loughran <st...@apache.org> wrote:
> Stefan Bodewig wrote:
>> you also changed ForkingJavaRmic to use isFailure() instead of the
>> exitCode == 0 check that was in it before. If rmic returns 0 on
>> success on OpenVMS, you've just broken the task.
>
> ooh, good point. Roll back?
That's why I suggested you ask the people from your OpenVMS group -
actually it would be good if at least one of them was subscribed here.
Maybe you've fixed the task and not broken it.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: svn commit: r405524 - in /ant/core/trunk/src: main/org/apache/tools/ant/taskdefs/Execute.java
main/org/apache/tools/ant/taskdefs/rmic/ForkingSunRmic.java testcases/org/apache/tools/ant/taskdefs/ExecuteWatchdogTest.java
Posted by Steve Loughran <st...@apache.org>.
Stefan Bodewig wrote:
> On Wed, 10 May 2006, Steve Loughran <st...@apache.org> wrote:
>> Stefan Bodewig wrote:
>>> On Tue, 09 May 2006, <st...@apache.org> wrote:
>>>
>>>> As well as simplifying a common operation, it is a foundation for
>>>> instance specific logic to decide if an execute failed, which
>>>> could be of use in VMS land.
>>> You better check with your contacts in the OpenVMS group for some
>>> of your changes. The tasks executing Java VMs (this includes tasks
>>> running rmic or javac) explicitly checked for a 0 exit code since
>>> we've been told the Java VM wouldn't be playing be OpenVMS rules
>>> and return 0 on success.
>>>
>> I havent actually done any vms-ready work, just wrapped up the
>> process of getting the return code then checking for a failure into
>> a method that is part of the Execute() instance.
>
> No, you also changed ForkingJavaRmic to use isFailure() instead of the
> exitCode == 0 check that was in it before. If rmic returns 0 on
> success on OpenVMS, you've just broken the task.
ooh, good point. Roll back?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: svn commit: r405524 - in /ant/core/trunk/src:
main/org/apache/tools/ant/taskdefs/Execute.java
main/org/apache/tools/ant/taskdefs/rmic/ForkingSunRmic.java
testcases/org/apache/tools/ant/taskdefs/ExecuteWatchdogTest.java
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 10 May 2006, Steve Loughran <st...@apache.org> wrote:
> Stefan Bodewig wrote:
>> On Tue, 09 May 2006, <st...@apache.org> wrote:
>>
>>> As well as simplifying a common operation, it is a foundation for
>>> instance specific logic to decide if an execute failed, which
>>> could be of use in VMS land.
>> You better check with your contacts in the OpenVMS group for some
>> of your changes. The tasks executing Java VMs (this includes tasks
>> running rmic or javac) explicitly checked for a 0 exit code since
>> we've been told the Java VM wouldn't be playing be OpenVMS rules
>> and return 0 on success.
>>
>
> I havent actually done any vms-ready work, just wrapped up the
> process of getting the return code then checking for a failure into
> a method that is part of the Execute() instance.
No, you also changed ForkingJavaRmic to use isFailure() instead of the
exitCode == 0 check that was in it before. If rmic returns 0 on
success on OpenVMS, you've just broken the task.
> Personally, I'm not 100% sure that you can have a zero-change switch
> to getting something like jboss to build on OpenVMs,
I agree.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: svn commit: r405524 - in /ant/core/trunk/src: main/org/apache/tools/ant/taskdefs/Execute.java
main/org/apache/tools/ant/taskdefs/rmic/ForkingSunRmic.java testcases/org/apache/tools/ant/taskdefs/ExecuteWatchdogTest.java
Posted by Steve Loughran <st...@apache.org>.
Stefan Bodewig wrote:
> On Tue, 09 May 2006, <st...@apache.org> wrote:
>
>> As well as simplifying a common operation, it is a foundation for
>> instance specific logic to decide if an execute failed, which could
>> be of use in VMS land.
>
> You better check with your contacts in the OpenVMS group for some of
> your changes.
>
> The tasks executing Java VMs (this includes tasks running rmic or
> javac) explicitly checked for a 0 exit code since we've been told the
> Java VM wouldn't be playing be OpenVMS rules and return 0 on success.
>
I havent actually done any vms-ready work, just wrapped up the process
of getting the return code then checking for a failure into a method
that is part of the Execute() instance.
For java checking we'd use the normal logic, and then if -and only if-
you switch to a new checker would a normal exec change its result checking.
Personally, I'm not 100% sure that you can have a zero-change switch to
getting something like jboss to build on OpenVMs, not if it <exec>s some
things and <java>s others. Though calling their build from another build
file that used <presetdef> to change exec default behaviours could maybe
pull it off.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: svn commit: r405524 - in /ant/core/trunk/src:
main/org/apache/tools/ant/taskdefs/Execute.java
main/org/apache/tools/ant/taskdefs/rmic/ForkingSunRmic.java
testcases/org/apache/tools/ant/taskdefs/ExecuteWatchdogTest.java
Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 09 May 2006, <st...@apache.org> wrote:
> As well as simplifying a common operation, it is a foundation for
> instance specific logic to decide if an execute failed, which could
> be of use in VMS land.
You better check with your contacts in the OpenVMS group for some of
your changes.
The tasks executing Java VMs (this includes tasks running rmic or
javac) explicitly checked for a 0 exit code since we've been told the
Java VM wouldn't be playing be OpenVMS rules and return 0 on success.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org