Return-Path: 
 <dev-return-46989-apmail-ant-dev-archive=ant.apache.org@ant.apache.org>
Delivered-To: apmail-ant-dev-archive@ant.apache.org
Received: (qmail 37729 invoked by uid 500); 12 Jun 2003 10:00:50 -0000
Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:dev-unsubscribe@ant.apache.org>
List-Subscribe: <mailto:dev-subscribe@ant.apache.org>
List-Help: <mailto:dev-help@ant.apache.org>
List-Post: <mailto:dev@ant.apache.org>
List-Id: "Ant Developers List" <dev.ant.apache.org>
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Delivered-To: mailing list dev@ant.apache.org
Received: (qmail 37708 invoked from network); 12 Jun 2003 10:00:49 -0000
Received: from unknown (HELO london.cellectivity.com) (212.18.242.163)
  by daedalus.apache.org with SMTP; 12 Jun 2003 10:00:49 -0000
X-MIMEOLE: Produced By Microsoft Exchange V6.0.5762.3
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: adding success & failure to <subant>
Date: Thu, 12 Jun 2003 11:01:01 +0100
Message-ID: <747F247264ECE34CA60E323FEF0CCC0C0F5104@london.cellectivity.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: adding success & failure to <subant>
Thread-Index: AcMwN4D1ung8M4ihT8+KdvUkaYnrjAAkCa5Q
From: "Jose Alberto Fernandez" <jalberto@cellectivity.com>
To: "Ant Developers List" <dev@ant.apache.org>
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

> From: Steve Loughran [mailto:steve_l@iseran.com]
>=20
> I think try and catch are better than failonerror stuff; the latter=20
> means a lot more complexity in the individual tasks, which means more=20
> testing (or worse test coverage).
>=20
> So I am in favour of try/catch moving into core.
>=20
> If/then/else is more controversial; I welcome input in that area
>=20

Using <if/> have simplified my builds enourmously. Before, for every =
little test I
needed to realize, I had to define a property which could only be set on =
some specific
task somewhere on the flow of the build. Then you had to write a =
separate target
if'd on that property so you will do or not do the work. My builds where =
so full of
these superflous targets that they became very hard to read.

Using <if/> really made the targets be real targets, and let small =
details on the flow
be managed by in a more clear and still declarative manner. <if/> is a =
declarative
construct well defined and without funny side effects, every declarative =
language
has such a construct and it does not causes any problems.

Jose Alberto

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org