Return-Path: Mailing-List: contact dev-help@ant.apache.org; run by ezmlm Delivered-To: mailing list dev@ant.apache.org Received: (qmail 78449 invoked from network); 18 Feb 2003 11:00:21 -0000 Received: from europa.heavens-door.net (212.77.229.2) by daedalus.apache.org with SMTP; 18 Feb 2003 11:00:21 -0000 Received: from gmx.de (fire2.mediatis.de [62.96.5.10]) (authenticated bits=0) by europa.heavens-door.net (8.12.2/8.12.1) with ESMTP id h1IB0BZV015946 for ; Tue, 18 Feb 2003 12:00:14 +0100 Message-ID: <3E521245.507@gmx.de> Date: Tue, 18 Feb 2003 12:00:21 +0100 From: Christopher Lenz Organization: mediatis GmbH User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en MIME-Version: 1.0 To: Ant Developers List Subject: Re: ant xdocs! it ran! References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Erik Hatcher wrote: > On Tuesday, February 18, 2003, at 04:29 AM, Christopher Lenz wrote: > >> Hi all, >> >>> Back to the original point of do not repeat ourselves... if we try to >>> invent some way of codifying such validation rules in @tags we'll end >>> up with the same out of sync issue. I'd rather us err on the side of >>> just using the English language (or perhaps localize it all somehow) >>> to define these loose things. This duplicates the validation rules a >>> little too, still, because they'll be in Java code and also in a text >>> description. These two will be in very close proximity though. >> >> >> With the disadvantage that the validation rules then can't be figured >> out by tools, which would be nice. > > > One step at a time :) > > It would be a major change attempt how Ant works. I think we need to Agreed. I just wanted to point out that formulating the validation rules just in english language will not help tool vendors with validation. Of course you're right that formulating them in Java code as well as in @tags is a violation of the DRY principle. But I think it'd be worthwhile to figure out a @tag scheme to support expressing the required/optional/default/attribute-set stuff, and live with the duplication for some time. At some point, Ant could migrate to using commons-attributes (or whatever it's called now, a project to allow querying of XDoclet-like "attributes" at runtime) to perform the validation outside the task. > accept how things work currently, and use those as our base assumptions > for this documentation overhaul. The tool integration is, at this > point, more of a "bonus" than an expressed need. I haven't heard the > Eclipse or NetBeans folks speak up here, although I know that NetBeans > has submitted several documentation patches to have Ant's task > documentation friendlier for their environment. > > I would love to hear what tool vendors have to say about this work and > where their thoughts are with Ant integration. I'm monitoring the Eclipse-Ant mailing list, and I have doubts that they are aware of this effort. Maybe someone should inform them. -chris