Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 53759 invoked from network); 8 Mar 2002 18:03:16 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 8 Mar 2002 18:03:16 -0000 Received: (qmail 26222 invoked by uid 97); 8 Mar 2002 18:02:57 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 26176 invoked by uid 97); 8 Mar 2002 18:02:57 -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 26106 invoked from network); 8 Mar 2002 18:02:56 -0000 X-Authentication-Warning: localhost.localdomain: costinm owned process doing -bs Date: Fri, 8 Mar 2002 10:01:35 -0800 (PST) From: X-X-Sender: To: Ant Developers List Subject: ProjectComponentHelper and adapters 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 I think I found a good solution for dealing with 'non-ant' tasks and types ( the adapters ), with the minimum amount of change. The story is simple: - ProjectComponentHelper is the hook that creates all components. Based on the component name, expected role ( which is a very extensible concept, right now it'll be DataType, Task - but we can refine this to deal with inner components, etc ) and ns the helper will create a Task, DataType, etc. - For 'normal' ant tasks/types things are simple, the real object is returned. - For 'external' objects ( Filter, regular beans ) an adapter must be returned. The current TaskAdapter is extremely limited and works only for tasks - but hopefully there is a simple and extremely powerfull solution - use RuntimeConfigurable. This solution resolves a lot of problems - it allows total freedom in how the components are 'adapted'. It requires few small changes in RuntimeConfigurable - to allow the returned adapter ( i.e. a Task/ DataType that wraps the external object ) to access the data in RuntimeConfigurable and get a chance to implement a custom behavior instead of the one hardcoded in RuntimeConfigurable. Comments ? One extra addition would be to refine a bit RuntimeConfigurable and make it less xml-specific, but that can be a separate proposal. Costin -- To unsubscribe, e-mail: For additional commands, e-mail: