Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 67500 invoked from network); 5 Nov 2001 16:50:41 -0000 Received: from unknown (HELO osaka.betaversion.org) (192.18.49.133) by daedalus.apache.org with SMTP; 5 Nov 2001 16:50:41 -0000 Received: (qmail 18401 invoked from network); 5 Nov 2001 16:53:04 -0000 Received: from nagoya.betaversion.org (192.18.49.131) by osaka.betaversion.org with SMTP; 5 Nov 2001 16:53:04 -0000 Received: (qmail 8299 invoked by uid 97); 5 Nov 2001 16:50:39 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 8282 invoked by uid 97); 5 Nov 2001 16:50:38 -0000 Mailing-List: contact ant-dev-help@jakarta.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 ant-dev@jakarta.apache.org Received: (qmail 8271 invoked from network); 5 Nov 2001 16:50:38 -0000 Message-ID: From: Tim Dawson To: Ant Developers List Subject: RE: [Ant2] Tasks as siblings of Date: Mon, 5 Nov 2001 10:50:41 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="UTF-8" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > a) restrict the possible tasks inside init to just those required (which > doesn't include all those property/available/etc) which most people would not > find useful > b) make thse constructs tasks which would require tight coupling between > runtime and tasks which would unduly restrict future evolution I disagree. There's no reason to make such a restriction that I can see. In fact, the property/available/etc. might be required in order to do task definitions properly. Right now, its possible to define a task after building it in the same file. Or at least it was with 1.3, I haven't tried it in a while because I'm on some new projects that don't need that. Executing the init target (if defined) would validate it (it would fail if it wasn't valid). You could then validate the rest of the file. Problem solved, as far as I can see. > c) not intuitive - imagine you had to search through a > java file for an init method and inside that was located > all the java import statements. No, I think its very intuitive. Imagine you had a method in every object that could get called when its created. Oh, wait, Java does have those, they're called constructors. :-) Tim -----Original Message----- From: Peter Donald [mailto:donaldp@apache.org] Sent: Thursday, November 01, 2001 10:20 PM To: Ant Developers List Subject: Re: [Ant2] Tasks as siblings of On Fri, 2 Nov 2001 09:12, Tim Dawson wrote: > Another issue that was raised that I don't quite understand is that > supposedly preprocess/validation requires top-level tasks. I mean, wouldn't > it be possible to just execute the init target, and then validate all the > other targets? this is effectively what happens if you have top level > tasks. Then you would need to a) restrict the possible tasks inside init to just those required (which doesn't include all those property/available/etc) which most people would not find useful b) make thse constructs tasks which would require tight coupling between runtime and tasks which would unduly restrict future evolution c) not intuitive - imagine you had to search through a java file for an init method and inside that was located all the java import statements. -- Cheers, Pete -------------------------------------------------- Where ignorance is bliss, 'tis folly to be wise. -------------------------------------------------- -- To unsubscribe, e-mail: For additional commands, e-mail: -- To unsubscribe, e-mail: For additional commands, e-mail: