ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominique Devienne" <>
Subject RE: 1.7 release timetable & features.
Date Thu, 24 Feb 2005 16:37:08 GMT
> From: Steve Loughran []
> Dominique Devienne wrote:
> > I'd like propertyset to stay as a property selector of sort, and not
> > into the realm of actually loading or defining properties. A
> > should stay has a collections of patterns to select existing
> > These patterns can be explicit, with the actual property name to
> > or more dynamic with startsWith/contains/regexp.
> yes, <propertyset> is probably the wrong place. But tasks that take
> properties (java &c) ought to be able to be driven by a file of
> properties that don't contaminate ant's own property space, and which
> may or may not be optional. Here is how I use it in a custom task:
>        <sf-startdaemon classpathref="run.classpath"
>          logStackTraces="true" spawn="true">
>            <!-- assertions are enabled -->
>          <assertions enableSystemAssertions="true">
>            <enable/>
>          </assertions>
>            <!-- load in a property file if it is present -->
>          <propertyfile file="${}" optional="true"/>
>        </sf-startdaemon>
> so, if there is a file that is present it gets loaded, if not, then
> The optional flag lets us indicate that it is an error if it is

Given that I don't know the <sf-startdaemon> task, it's difficult to
gage whether the properties loaded from ${} are used
as properties, i.e. the task also supports a <property> or <param> or
<propertyset> nested element (e.g. <java>, <junit>, <ant>, <antcall>,


the more controversial use of the property name/value pairs as
definitions for the task's own attributes (instead or in addition to
writing them in the build file), as was proposed recently. The latter I
don't like much. --DD

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message