Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 91076 invoked from network); 9 Mar 2002 16:01:30 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 9 Mar 2002 16:01:30 -0000 Received: (qmail 25619 invoked by uid 97); 9 Mar 2002 16:01:28 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 25576 invoked by uid 97); 9 Mar 2002 16:01:28 -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 25565 invoked from network); 9 Mar 2002 16:01:27 -0000 X-Authentication-Warning: localhost.localdomain: costinm owned process doing -bs Date: Sat, 9 Mar 2002 07:59:53 -0800 (PST) From: X-X-Sender: To: Ant Developers List Subject: Re: ProjectComponentHelper and adapters In-Reply-To: <012601c1c749$276d2950$0100a8c0@jose> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Sat, 9 Mar 2002, Jose Alberto Fernandez wrote: > Ok, I should sound like a broken record by now, but how do you plan to solve > the case of data-types that DO NOT EXTEND from o.a.t.ant.types.DataType? I allways have problems explaining - I answered this several times before, it is a non-issue - we already do that for tasks that do not extend o.a.t.ant.Task, it works reasonably well ( I have few dozen tasks of this kind ). All you need is an adapter - for tasks we use TaskAdapter, something similar will be done for DataType. The factory returns either a Task or a DataType. If the component implements the interface, no problem. If not - we return a TaskAdapter or DataTypeAdapter, implementing the interface and wrapping the non-ant object. By extending the use of RuntimeConfigurable, the adapter can even implement arbitrary policies for 'adaptation' - you can adapt an object that doesn't even follow ant patterns of setters, or execute(). Sorry for not beeing very clear in my explainations. > > For consistency, we should have all tasks use the RuntimeConfigurable, > > even if they are top level - but that's again a change in the > > xml processor, can be done outside. > > Somebody else mentioned that maybe we should be using UnknownElement or > NestedElement all the way during construction and delay the actual expansion > to just before usage (or when someone actually tries to access the Task out of the Target. I would consider UnknownElement and NestedElement more of an internal for the helper. But if we need to - we can use them as well. > The only special case is with "id" references that would have to be resolved when they > are used, (if not resolved yet). Doesn't seem like a huge problem. > If we could a consensus on how to do that we could reduce ProjectHelper cruft by at least > 80% (at least in the version in proposal) and we would finish with a completely > regular set of rules for constructing and evaluating the tree. And all that could be done in a real > backward compatible way. And yes we could get rid of all those invalidation tables in the code. It seems 'consensus' is not very easy - that's why making the core more flexible ( by adding hooks and modularizing ) is so important. If we add the right hooks, the consensus will not matter that much, any solution will be implementable without requiring consensus ( as an external plugin ), and if successful it'll be much easier to make it part of the core. And will allow the various ant2 features to be implemented and used with ant1 - so we can have a gradual transition, decide which implementations we want and which features are indeed usefull. And when we have everything, we can bump the version number and remove deprecated stuff. Costin -- To unsubscribe, e-mail: For additional commands, e-mail: