Return-Path: Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 54262 invoked from network); 28 May 2000 03:36:02 -0000 Received: from unknown (HELO smtp.geniesystems.com) (203.98.41.86) by locus.apache.org with SMTP; 28 May 2000 03:36:02 -0000 Received: (qmail 15641 invoked from network); 28 May 2000 03:22:29 -0000 Received: from raphael.akl.nz.geniesystems.com (HELO raphael.geniesystems.com) (10.64.10.11) by renoir.akl.nz.geniesystems.com with SMTP; 28 May 2000 03:22:29 -0000 Received: by raphael.geniesystems.com with Internet Mail Service (5.5.2650.21) id ; Sun, 28 May 2000 15:20:48 +1200 Message-ID: <81207B0C8081A24795F1C382D9E2B13002608F@raphael.geniesystems.com> From: Aaron Knauf To: "Ant Developers (E-mail)" Subject: Task/Target Exit status, conditional processing and logging Date: Sun, 28 May 2000 15:20:39 +1200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N -----BEGIN PGP SIGNED MESSAGE----- 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="some.property.set" 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: 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 org.apache.tools.ant.AntConstants, 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 refinements/comments? ADK -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.2 for non-commercial use iQA/AwUBOS/ojtDEY7hlrDuMEQLuJACg9Mbu/ceZAkSY3Z9CntDyfQBbfTsAnA9M Ft42UVFkjrVDpb0bdO0NbMEF =uP7z -----END PGP SIGNATURE-----