ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Oxspring" <roxspr...@yahoo.com>
Subject RE: Property substitutions, Contributed Tasks, & New features
Date Thu, 18 Jan 2001 04:30:19 GMT
On the defaults thread...

What about the properties already set in the project's environment? I
realise that these are slightly contrived examples, but consider user.home,
java.version & os.name; if the java task has a version attribute won't it
cause some confusion to have the JVM set the value? - especially since
setting the property otherwise in the build file will not override the
system properties. As a work around to this problem maybe the prefix
"default." should be added eg:

<property name="default.copy.filter" value="on"/>

This still doesn't resolve the nested elements issue.  The order of nested
tags can potentially be important too, so maybe something along the lines of
adding an order number could resolve this:

javadoc.doclet.name=org.someone.doclet.DevByContract
javadoc.doclet.path=/tools/contract.jar
javadoc.doclet.param#1.name=strict
javadoc.doclet.param#1.value=yes
javadoc.doclet.param#2.name=verbose
javadoc.doclet.param#2.value=no

Even with this though, what about the following code (assuming other
defaults were filled in for the javadoc tag).

<javadoc>
	<doclet>
		<param name="foo" value="bar"/>
	</doclet>
</javadoc

Presumably the doclet attribute would be appropriately set, but what params
would be presented to the doclet? Logically the options must be
strict+verbose,foo+verbose, possibly strict+verbose+foo; but the option that
seems sensible is to ignore the defaults in this case and force everything
back to being explicit.

Personally I prefer the idea of using something xml based to set the
defaults eg:
<default>
	<javadoc>
		<doclet name="org.someone.doclet.DevByContract"
			path="/tools/contract.jar">
			<param name="strict" value="yes"/>
			<param name="verbose" value="no"/>
		</doclet>
	</javadoc>
</default>
...
<javadoc ... />

... though I appreciate this cannot be "included" as easily as a properties
file so maybe this could be a Ant2 suggestion.

Just a few thoughts,

Rob


> -----Original Message-----
> From: Sam Ruby [mailto:rubys@us.ibm.com]
> Sent: 12 January 2001 17:26
> To: ant-dev@jakarta.apache.org
> Subject: Re: Property substitutions, Contributed Tasks, & New features
>
>
> 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
>
>
>
>
> ---------------------------------------------------------------------
> 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