Return-Path: Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 75200 invoked from network); 22 Jun 2000 12:38:20 -0000 Received: from me-sv-02.free.net.au (202.147.17.2) by locus.apache.org with SMTP; 22 Jun 2000 12:38:20 -0000 Received: (qmail 11216 invoked from network); 22 Jun 2000 12:37:39 -0000 Received: from me-as-03-124.free.net.au (HELO donalgar) (202.147.20.124) by me-sv-02.free.net.au with SMTP; 22 Jun 2000 12:37:39 -0000 Message-Id: <3.0.5.32.20000622223922.007ddcf0@latcs4.cs.latrobe.edu.au> X-Sender: pjdonald@latcs4.cs.latrobe.edu.au X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Thu, 22 Jun 2000 22:39:22 +1000 To: ant-dev@jakarta.apache.org From: Peter Donald Subject: Re: [RFE] Richer Task Specification In-Reply-To: References: <3.0.5.32.20000620184502.0081e100@latcs4.cs.latrobe.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N At 03:01 22/6/00 -0700, you wrote: >on 2000/06/20 01:45, Peter Donald at donaldp@mad.scientist.com wrote: > >> well if I was a voting member I would go +1 but because I aint I will just >> say good :P. Thou don't see why the properties/taskdefs don't get treated >> exactly like tasks (except that maybe they can never be overidden) so are >> you asking for just a philosophical distinction and safety net so some-one >> cant add their own task named taskdef ??? > >No, a chicken is not a worm is not a mammal. Properties != Taskdefs != >Tasks. Sure, you could drive taskdefs from properties (or even derive such >as taskdef extends property but since this is XML and not Java...), but I >think that they really should be seperate beasts and treated as seperate >collections of things. I understand they are philosophically different and should be treated as differently by ant-processor but ... They could be implemented as tasks and executed immediately (ie when you get to them). They would still be treated differently because you won't be able to have arbitary tasks in main part of build file only properties/taskdefs/target tasks. Implementation wise it is _good_ IMHO(virtually no special case code) and it could be still kept seperate philosophically. I still don't understand properties thou and none of the archives seem to explain it (maybe I just thick :P) so I would love for some one to explain it as it stands now. I saw references to removeing ${}, making them entities treating the variables through available and properties as constants but I still have no idea how it was decided (or if it was) what they are going to be. Cheers, Pete *------------------------------------------------------* | "Nearly all men can stand adversity, but if you want | | to test a man's character, give him power." | | -Abraham Lincoln | *------------------------------------------------------*