Return-Path: 
 <ant-dev-return-13782-apmail-jakarta-ant-dev-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-ant-dev-archive@jakarta.apache.org
Received: (qmail 13960 invoked by uid 500); 16 May 2001 05:22:16 -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 13947 invoked from network); 16 May 2001 05:22:15 -0000
From: "Conor MacNeill" <conor@cortexebusiness.com.au>
To: <ant-dev@jakarta.apache.org>
Subject: RE: if and unless attributes for all Tasks
Date: Wed, 16 May 2001 15:24:01 +1000
Message-ID: <NDBBIMHCHMPELMBMMFIMKEIHFJAA.conor@cortexebusiness.com.au>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <3.0.6.32.20010516150018.00acd5a0@mail.alphalink.com.au>
X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N

> From: Peter Donald [mailto:donaldp@apache.org]
>
> if you mean the ant-calls for src and bianry distributions then I agree -
> UGLY ;) Though it is better than any alternative I could think of - you ?

True enough. I think we are using these antcalls primarily as a way to get
around the immutable properties in Ant - right? So, I see these resulting
from another Ant "feature". We solve that problem using the tools at hand -
antcall.

It is the same with if and unless. Those are the tools we have provided and
a lot of problems can be solved that way, but sometimes it forces the build
writer into unnatural contortions. The end result is that the build file is
complex and the intent of the build file's author is lost. Compare Jose
Alberto's target based example against the original in the patch. It works
in the current Ant, but is it better?

I like this discussion since we should always be ready to question whether
there is a better way of doing things. That is why I'd like to hear from Jon
on his thoughts for a better way of doing the uptodate checks. uptodate is a
direct result of the if/unless mechanisms we currently have. Is there a
better way?

>
> >Is writing tasks the right way? I'm not sure that is true.
>
> Could you explain why? ie What do you see wrong with writing a task for
> complex build "tasks".

I see tasks as appropriate when you tend to do the same type of things in
many places or in many builds. That is, I see them as a solution when you
can apply them in multiple places. I'm wary of using tasks for ad-hoc
conditional requirements in the build. Can you see a task or tasks for the
Ant build that handles all the conditionals we currently have. Look at the
<exclude> elements in the compilation. Moving that into its own task would
make the build much more difficult to understand. At one extreme it would
become
<buildant>

:-)

>
> If you are referring to the initial setting of properties and general
> autoconf-like features then I agree that writing a task is
> overkill as most
> tests will be project specific. (I believe autoconf should be written in
> some scripting language like jython/rhino or another BSF mounted scripting
> language). However for the other stuff I think task writing is
> the WAY to go.
>

So, why don't we use that in the ant build file? WOuld it be better, more
easily maintained? I'm not convinced.

BTW, I'm not arguing for any particular view. I'm not sure what is the best
compromise, myself.

Conor