ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Knauf <>
Subject Task/Target Exit status, conditional processing and logging
Date Sun, 28 May 2000 03:20:39 GMT
Hash: SHA1

This whole exit status thread was kicked off by a post about figuring
out what Javac did.  I replied to that post because I am interested
in a more generic exit status mechanism.  There is one situation in
which I would use an exit status - 

if that returned x, do this

Now that is really just a way of doing conditional processing within
a target.  One alternative would be to split up the target in to
several smaller targets with if="" clauses.  The
only issue with this method is that a Task may fail in a variety of
ways and this will only stop the build if the Task author decides to
throw a BuildException at the point.  The build.xml author has no
control over what degree of failure he will accept.  e.g. Are we
happy to continue the build if warnings are issued by javac?

So we require two things to facilitate this:

1.	Support for degrees of success
2.	Standardisation on what constitutes a BuildException (and
therefore a build failure).

I liked the idea of using a BuildError as well as a BuildException
(posted by Vitaly Stulsky), at first.  Then I figured that nailing
down point two would become too hard.  Instead, we could use
BuildException for internal Ant problems only (things that are
probably caused by a bug), and use log() with severity levels for all
other conditions.  We could then use a threshold property to specify
the severity level at which the build is stopped, the next target
started, etc.

As for where to put the exit status and how to access it: 

<target name="example" status="example.status"
	<ATask which exits with status="NOTICE" />

<target name="paranoid" depends="example"
checkstatus="example.status" acceptstatus="INFO" >

1.	Running target "paranoid" causes "example" to run first.
2.	Target "example" will abort the build if a task returns WARNING or
worse (which should be a 'public static final' field defined in, or similar).
3.	Target "paranoid" checks the "example.status" property and will
only run if it contains a status value not worse than "INFO".  As
"example" had a task that exited with status "NOTICE" (which is worse
than warning), target "paranoid" will not run.

"example.status" should contain the exit status returned by the last
task in the target.

A SetStatus task could be used to explicitly set the status.  The
property task could also write to the property specified in the
status= attribute. SetStatus would guarantee that the correct
property was modified (using a call to Target) and that a legitimate
status value was used.

Not bothering to specify these attributes should make ant use default
settings which are equivalent to current operation.

I think that going any further than this becomes the domain of BSF.

NOTE: The exit statuses used here would be set using the log() call. 
This would require most BuildExceptions currently thrown by Tasks to
be changed into log() calls.  Not making this change would mean that
that Task could not participate in this mechanism.

My goal here is to put as much control as possible into the build.xml
author's hands, without breaking existing functionality or requiring
additional syntax to be learned.

Well, that's my 2 cents worth.  It's a little raw. Anyone have any


Version: PGPfreeware 6.5.2 for non-commercial use <>


View raw message