Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 16530 invoked from network); 5 Jan 2002 03:27:24 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 5 Jan 2002 03:27:24 -0000 Received: (qmail 24629 invoked by uid 97); 5 Jan 2002 03:27:30 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 24613 invoked by uid 97); 5 Jan 2002 03:27:29 -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 24602 invoked from network); 5 Jan 2002 03:27:29 -0000 From: "Adam Murdoch" To: "Ant Developers List" Subject: RE: IntrospectionHelper request Date: Sat, 5 Jan 2002 13:26:46 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <015601c19584$1bd6fae0$6401a8c0@darden.virginia.edu> Importance: Normal X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Hi, The Myrmidon patch I submitted last week did this, more or less. Configuration was done via interfaces (there was even one called AttributeSetter, as it turns out). The piece that is missing (and this was at the top of my "what-i-want-to-do-next" list) was some way for a class to hand its custom introspector to the configurer. The short-term plan was to simply use a static method, called something like "getConfigurer()". If present, the configurer would use whatever it returned, if not present, the default introspector would be used. The longer-term plan was to grow the introspector stuff into the TaskInfo. Either way, I think it would be a useful thing to allow a class (data type or task) to have programmatic control over its meta-info. Whatever mechanism is used should ideally allow meta-info from all 3 sources to be mixed and matched as the task writer chooses. The 3 "sources" would be: - introspection - the task descriptor (ie the javadoc comments or whatever) - the class itself (programmatic). Not so sure about doing this kind of stuff in the Ant 1 tree. For one, there's the whole backwards compatibility thing - all the introspection stuff is public, and is, strictly speaking, part of the API. Also, it would be good to spend a while playing with this stuff, to do some prototyping and get the concepts sorted out a little better (e.g. it may well be flexibility syndrome). The Ant 1 tree is not a good place to be experimenting. Adam > -----Original Message----- > From: Erik Hatcher [mailto:jakarta-ant@ehatchersolutions.com] > Sent: Saturday, 5 January 2002 10:56 AM > To: ant-dev > Subject: IntrospectionHelper request > > > While inquiring about some issues I was having with my attempts to get > XDoclet custom templates working (very cool, by the way!), I got this > request for Ant: > > "Please make IntrospectionHelper an interface with a default/derivable > impl. I want to extend it and add a new kind of introspection, but > everything seems to be concrete and utility class. Specifically I want > to create my own AttributeSetter and instead of invoking a setter method > in the target task/element, set a config param value in a hashtable > field of the target element, or in other words I want to add a more > dynamic approach so the user can add config params without having to > create a DocletTask-derived class and getter/setter there." > > I don't quite have the bandwidth or intimate know-how of > IntrospectionHelper > yet to give a good response. Thoughts?? > > Erik > > > > -- > To unsubscribe, e-mail: > For additional commands, e-mail: -- To unsubscribe, e-mail: For additional commands, e-mail: