ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn McAllister <gl...@somanetworks.com>
Subject Re: Property substitutions, Contributed Tasks, & New features
Date Fri, 12 Jan 2001 14:47:08 GMT
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


Mime
View raw message