From james.davidson@eng.sun.com Mon Feb 28 19:07:36 2000 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 63177 invoked from network); 28 Feb 2000 19:07:36 -0000 Received: from mercury.sun.com (192.9.25.1) by locus.apache.org with SMTP; 28 Feb 2000 19:07:36 -0000 Received: from shorter.eng.sun.com ([129.144.123.35]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA10528 for ; Mon, 28 Feb 2000 11:07:35 -0800 (PST) Received: from ionic (hobo123.EBay.Sun.COM [129.150.99.123]) by shorter.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with SMTP id LAA29376 for ; Mon, 28 Feb 2000 11:07:33 -0800 (PST) Message-ID: <049101bf821f$434f22c0$83639681@ionic> From: "James Duncan Davidson" To: References: <85256893.000E7688.00@d54mta04.raleigh.ibm.com> <38BA7592.EECC3DF7@websitewatchers.com> Subject: Re: Controversial task Date: Mon, 28 Feb 2000 11:07:24 -0800 Organization: Sun Microsystems, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N > - lots of rmic: for that one i had to write a generator of tags that takes the > list of implementation > class and generates the tags to build the stubs for them. A for loop is > an easy solution, > but we might as well extand the functionallity of rmic so that it can discover > the remote classes > in a folder and generate the stubs for them This solution of an rmicdir task (or some such name) that would reflect into all classes and find the remote classes would be a decent thing to do. > Ok, so far I've just proved that foreach *might* be useful in sporadic > situations but the need for > it reflects more other problems in the existing tasks. I don't think that you've proved that control structures are necessary. I think that you've proved that there are task types that can be introduced that make life easier for the XML writer and which do more of the logic. > (it would be nice also to have a serialver task) Sure. Write one up. :) > Can we consider some kind of extension mecanism to ant? I find that having to > define > in each project is a pain (especially is you have >10 projects...). I've seen > that you can read default > properties from your home directory, why not have that also for default > taskdefs? That's not a bad idea as well. Having a $HOME/.antrc or some such would not be a bad thing imho. .duncan