ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Ruby" <ru...@us.ibm.com>
Subject Re: Property substitutions, Contributed Tasks, & New features
Date Fri, 12 Jan 2001 17:25:32 GMT
Glenn McAllister wrote:
>
> 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

My preference would be (whitespace added for clarity):

   javadoc.doclet={
     name=org.someone.doclet.DevByContract,
     path=/tools/contract.jar,
     parm={name=strict,value=yes},
     parm={name=verbose,value=no}
   }

On the command line, this typically would be done without any whitespace.
Inside the build.xml file, it would require the ability to have nested
properties, and would have a XML style syntax.  It could be shoe-horned
into an ini-style syntax much like it can be on the command line, but
realistically an XML or CSS style syntax would be much more appropriate.

- Sam Ruby


Glenn McAllister <glenn@somanetworks.com>@dryline-fw.wireless-sys.com on
01/12/2001 09:47:08 AM

Please respond to ant-dev@jakarta.apache.org

Sent by:  glenn@dryline-fw.wireless-sys.com


To:   ant-dev@jakarta.apache.org
cc:
Subject:  Re: Property substitutions, Contributed Tasks, & New features



Sam Ruby wrote:

> Taking this a step further, I would make any task's attribute default to
> ${<task>.<attribute>}.  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


---------------------------------------------------------------------
To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: ant-dev-help@jakarta.apache.org




Mime
View raw message