Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 46894 invoked from network); 16 Sep 2002 08:30:08 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 16 Sep 2002 08:30:08 -0000 Received: (qmail 18155 invoked by uid 97); 16 Sep 2002 08:30:55 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 18139 invoked by uid 97); 16 Sep 2002 08:30:55 -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 18127 invoked by uid 98); 16 Sep 2002 08:30:54 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) From: "Leo Sutic" To: "'Ant Developers List'" Subject: RE: private to protected and extensibility of Ant Date: Mon, 16 Sep 2002 10:31:31 +0200 Message-ID: <000101c25d5b$7670db70$0801a8c0@Lagrange> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <3D846742.4040405@ehatchersolutions.com> X-OriginalArrivalTime: 16 Sep 2002 08:30:14.0673 (UTC) FILETIME=[47BC6010:01C25D5B] X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > From: Erik Hatcher [mailto:jakarta-ant@ehatchersolutions.com] > > > 1) The taskdefs are not supposed to be extended by users. I would > > argue > > that they should be. Ant is supposed to be extended by > users writing > > their own tasks, and using the existing tasks as base > classes is, in my > > opinion, a natural first step. I agree that the Ant kernel > is off-limits > > to users, though. > > I take some issue with this. The classes corresponding with the > are not what I'd consider something folks should extend, > generally speaking. I feel these classes should be more of a facade or > wrapper over underlying API that is to be designed for reusability. > Does that make sense? For example, the task uses a more > generalized API under the cover to execute native programs. So, rather > than extending ExecTask, make your own task and use Execute under the > covers to do the work. OK... Yes, I can see that being more robust in the long run... The lazy eval can then be done not by the property class but in the task encapsulating the Ant task. I'll try to go that route first. Thanks! /LS -- To unsubscribe, e-mail: For additional commands, e-mail: