Return-Path: 
 <dev-return-49924-apmail-ant-dev-archive=ant.apache.org@ant.apache.org>
Delivered-To: apmail-ant-dev-archive@ant.apache.org
Received: (qmail 61726 invoked by uid 500); 25 Aug 2003 16:10:09 -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 61699 invoked from network); 25 Aug 2003 16:10:08 -0000
Received: from unknown (HELO olinexvs01.olin.edu) (4.21.173.2)
  by daedalus.apache.org with SMTP; 25 Aug 2003 16:10:08 -0000
Received: from olinexfe01.olin.edu ([10.1.15.93]) by olinexvs01.olin.edu with
 Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 25 Aug 2003 12:08:33 -0400
Received: from cognition.olin.edu ([4.36.33.205])
 by olinexfe01.olin.edu (SAVSMTP 3.0.0.44) with SMTP id M2003082512083213972
 for <dev@ant.apache.org>; Mon, 25 Aug 2003 12:08:33 -0400
Message-ID: <3F4A329B.2060702@cognition.olin.edu>
Date: Mon, 25 Aug 2003 12:00:27 -0400
From: Gus Heck <gus-antdev@cognition.olin.edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ant Developers List <dev@ant.apache.org>
Subject: Re: [new tasks] presetdef and macrodef
References: <747F247264ECE34CA60E323FEF0CCC0C0F512F@london.cellectivity.com>
In-Reply-To: <747F247264ECE34CA60E323FEF0CCC0C0F512F@london.cellectivity.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 25 Aug 2003 16:08:33.0999 (UTC)
 FILETIME=[224CC5F0:01C36B23]
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

>
>
>>Templates appear to be something new, though I don't think I 
>>like them 
>>(see below)
>>
>>    
>>
>>> (1) --> ${xyz}
>>> (2) --> ${macroattr:xyz}
>>> (3) --> ${macrotemplate:xyz}
>>>
>>>      
>>>
>
>Well, as I said I use those terms above just as examples, I am not
>hookup in words, 
>I was just looking for some identifier to describe them. Still the
>concepts
>I am expressing are very clasical ones, these are not things out of the
>blue.
>
I would personally prefer a slightly more distinct syntax that didn't 
use ${} for things that arn't exactly properties. Looking at it another 
way: your suggestion is a half-magic property :) It reserves property 
names starting with macroattr: and macrotemplate: as special, and 
different from other properites.

>>If macro definitions are available to sub builds, then your 3rd case 
>>might occur, but I don't think it would be good to allow macros to be 
>>called across build file boundaries. builds would be almost 
>>unintelligible without tracking down the macros from other files.
>>
>>    
>>
>
>This is all regular kosher ANT stuff, up to this day, <taskdef/>s get
>inherited, they do not need to be redeclared for the task to be
>available
>during the <antcall/>. Are you proposing that we have a different,
>special case,
>semantics for <macrodef>?
>  
>
I hadn't realized that taskdefs did this, but if it were up to me I 
wouldn't have designed it this way. I would prefer to see the taskdefs 
in each build file, so that I don't have to find out who's calling the 
buildfile to find out where to find out what the task does. Any time you 
get that many find-outs in a sentance it is clearly a royal pain in the 
making (imho). :).

In otherwords, I would have prefered the simple rule, "if it isn't part 
of the standard distro of ant, there will be a taskdef in the build to 
tell you what it is." I don't think saving a few extra lines of typing 
(or cut/paste) for the taskdefs is really worth making the build 
unreadable without reference to another build (which won't be known 
unless it appears in a comment).

I havn't followed the antlib topic closely enough (I havn't followed it 
at all really because of the sheer volume of mail on those threads, and 
the need to get some of my own work done :) ), but I get the impression 
that antlib might reasonably eliminate the taskdef stuff by creating a 
single place to look for definitions of things that arn't part of the 
standard distro. and that would be fine. I only object to having to 
having the builds depend on things defined in other builds with no 
pointer to the definition (or standard location for the definition).

-Gus


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