Return-Path: Delivered-To: apmail-ant-dev-archive@www.apache.org Received: (qmail 22268 invoked from network); 4 Jun 2004 16:07:45 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 4 Jun 2004 16:07:45 -0000 Received: (qmail 11874 invoked by uid 500); 4 Jun 2004 16:07:32 -0000 Delivered-To: apmail-ant-dev-archive@ant.apache.org Received: (qmail 11627 invoked by uid 500); 4 Jun 2004 16:07:30 -0000 Mailing-List: contact dev-help@ant.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list dev@ant.apache.org Received: (qmail 11387 invoked by uid 99); 4 Jun 2004 16:07:28 -0000 Received: from [134.132.72.99] (HELO junior.lgc.com) (134.132.72.99) by apache.org (qpsmtpd/0.27.1) with ESMTP; Fri, 04 Jun 2004 09:07:28 -0700 Received: from lgchvw01.lgc.com (lgchvw01.lgc.com [134.132.93.107]) by junior.lgc.com (8.11.7/8.11.3) with SMTP id i54Emc402686 for ; Fri, 4 Jun 2004 09:48:38 -0500 (CDT) Received: from 134.132.93.152 by lgchvw01.lgc.com (InterScan E-Mail VirusWall NT); Fri, 04 Jun 2004 09:49:39 -0500 Received: by lgchexchbh.ad.lgc.com with Internet Mail Service (5.5.2657.72) id ; Fri, 4 Jun 2004 09:49:38 -0500 Message-ID: From: Dominique Devienne To: "'Ant Developers List'" Subject: RE: Generic tasks/types WAS Possible Ant 1.7 alpha bug: property expansion. Date: Fri, 4 Jun 2004 09:49:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N > From: Stefan Bodewig [mailto:bodewig@apache.org] > On Fri, 4 Jun 2004, Matt Benson wrote: > > If there is any reason why we couldn't/shouldn't have > > a generic DynamicConfigurator that could > > execute an arbitrary task by classname, and a generic > > or , probably also a > > DynamicConfigurator, to instantiate (and optionally > > configure) an arbitrary object, usu. to set as a > > reference, but possibly for other things as well... > > Ahh!! > > No, I don't see any reason why we shouldn't have a task/type like > this. This actually ties back to what Magesh proposed (the dispatch task). One of the useful bit his proposal allowed was to conditionally execute one mode or the other thanks to mode="${mode}", where mode can be configured/computed before-hand. If we had a way to configure and execute a task in a similar indirect way, we'd achieve the same goal, will still using different tasks. Here's what I mean: You have tasks A and B which are interchangeable, i.e. take the same attributes and nested elements, but do different things. Instead of doing: if some-condition do-A else do-B or doing Magesh's some-condition [elements] We'd do something like: some-condition [elements] This allows the necessary indirection, and avoids having to Duplicate all the attributes and elements in an . This is similar to XSL's , where the great majority of time you just output the element directly, as in , but sometime need to dynamically set the elements name, thanks to . Anyways, I hope this makes sense. --DD --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org For additional commands, e-mail: dev-help@ant.apache.org