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 <[EMAIL PROTECTED]>@dryline-fw.wireless-sys.com on
01/12/2001 09:47:08 AM
Please respond to [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
