Return-Path: Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 75740 invoked from network); 12 Jan 2001 14:47:07 -0000 Received: from dryline-fw.wireless-sys.com (216.126.67.45) by h31.sny.collab.net with SMTP; 12 Jan 2001 14:47:07 -0000 Received: from somanetworks.com (glenn@watto.yyz.somanetworks.com [10.11.11.34]) by dryline-fw.wireless-sys.com (8.8.7/8.8.7) with ESMTP id JAA10943 for ; Fri, 12 Jan 2001 09:47:08 -0500 Sender: glenn@dryline-fw.wireless-sys.com Message-ID: <3A5F18EC.71B09041@somanetworks.com> Date: Fri, 12 Jan 2001 09:47:08 -0500 From: Glenn McAllister Organization: SOMA Networks X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: ant-dev@jakarta.apache.org Subject: Re: Property substitutions, Contributed Tasks, & New features References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Sam Ruby wrote: > Taking this a step further, I would make any task's attribute default to > ${.}. Now I can control deprecation on compiles, the > window title on javadoc, the useTimestamp option on get, the jvmarg on > java, ... all from the command line! I'd give a big +1 to this for its sheer simplicity. The only concern I have is nested elements - does this mechanism still work cleanly? Lets pick on doclets, as its a reasonable complicated yet plausible situation. Our vanilla build file has a target to build javadoc for the system. By default, we use the Standard doclet from Sun. Now lets say a QA guy wants to use one of the "development by contract" doclets out there. It requires two parameters: strict (yes/no), verbose (yes/no). (And yes, I know these would have defaults, but just play along. :-] ) So, we use the new mechanism to specify this on the command line, eliminating the need for changes to the build.xml file. Sounds good so far. Say I we have javadoc.doclet.name=org.someone.doclet.DevByContract javadoc.doclet.path=/tools/contract.jar javadoc.doclet.param.name=strict javadoc.doclet.param.value=yes javadoc.doclet.param.name=verbose javadoc.doclet.param.value=no Now what? I have two param's I have to include, but the syntax above only supports one. Also, the original Javadoc task never had a doclet element to begin with. Do we automatically create nested elements as required (and allowed by the task)? Any thoughts? Glenn McAllister