Return-Path: 
 <ant-dev-return-17498-apmail-jakarta-ant-dev-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-ant-dev-archive@jakarta.apache.org
Received: (qmail 29654 invoked by uid 500); 11 Sep 2001 06:00:41 -0000
Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ant-dev@jakarta.apache.org
list-help: <mailto:ant-dev-help@jakarta.apache.org>
list-unsubscribe: <mailto:ant-dev-unsubscribe@jakarta.apache.org>
list-post: <mailto:ant-dev@jakarta.apache.org>
Delivered-To: mailing list ant-dev@jakarta.apache.org
Received: (qmail 29632 invoked from network); 11 Sep 2001 06:00:41 -0000
X-Authentication-Warning: bodewig.bost.de: bodewig set sender to
 bodewig@apache.org using -f
To: ant-dev@jakarta.apache.org
Subject: Re: [PATCH] Allow "if" and "unless" attributes on the Sequential and
 Parallel tasks
References: <3B8571EE.2030702@sedonacorp.com> <m3ae0q10xc.fsf@bodewig.bost.de>
	<3B86A01E.80500@sedonacorp.com>
From: Stefan Bodewig <bodewig@apache.org>
Date: 11 Sep 2001 08:00:46 +0200
In-Reply-To: Matthew Inger's message of "Fri, 24 Aug 2001 14:42:38 -0400"
Message-ID: <m3n142qnap.fsf@bodewig.bost.de>
Lines: 44
User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Cuyahoga Valley)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

Sorry for the late reply Matthew, I've been on vacation.

On Fri, 24 Aug 2001, Matthew Inger <matti@sedonacorp.com> wrote:

> I'm not saying it has to be a catch all, but i don't see what the
> issue is with allowing the simple if and unless attributes on the
> two above tasks.

Depends on what you want to accomplish with/for Ant.

There are several tasks that may deserve an if/unless attribute and
where not having the attributes leads to rather complicated constructs
- <fail> is the prime example.

The committers of Ant have more than once declined if/unless
attributes for tasks in general - just look up the discussion around
Ant2 in the archives.

I'm not saying that these attributes couldn't lead to cleaner and
easier to understand build files if they were available, but they also
have to potential to achieve the opposite effect.  People start using
<antcall> instead of the superior depends attribute of target for
example, just because it is there.

> Being that they already exist on the "<target>" tag, I don't see how
> it's any different to allow them the sequential and parallel tags.

<target> is not a task.

My argument was that having an if attribute on <sequential> is an <if>
task in disguise and I'd prefer a full blown <if> task any time as
your suggestion will lead to 

<condition property="some-prop">
  ...
</condition>
<sequential if="some-prop">
  ...
</sequential>

for everything that is a bit more complicated than just looking up a
single property.  This is the same bloat you wanted to avoid.

Stefan