ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominique Devienne" <DDevie...@lgc.com>
Subject RE: 1.7 release timetable & features.
Date Thu, 24 Feb 2005 16:37:08 GMT
> From: Steve Loughran [mailto:stevel@apache.org]
> 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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message