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
