> From: Steve Loughran [mailto:[EMAIL PROTECTED]
> Dominique Devienne wrote:
> > I'd like propertyset to stay as a property selector of sort, and not
go
> > into the realm of actually loading or defining properties. A
propertyset
> > should stay has a collections of patterns to select existing
properties.
> > These patterns can be explicit, with the actual property name to
select,
> > 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="${runtime.properties}" optional="true"/>
> </sf-startdaemon>
>
> so, if there is a file that is present it gets loaded, if not, then
not.
> The optional flag lets us indicate that it is an error if it is
missing.
Given that I don't know the <sf-startdaemon> task, it's difficult to
gage whether the properties loaded from ${runtime.properties} are used
as properties, i.e. the task also supports a <property> or <param> or
<propertyset> nested element (e.g. <java>, <junit>, <ant>, <antcall>,
etc...)
OR
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
