ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Dawson <tdaw...@is.com>
Subject question: filter
Date Thu, 01 Mar 2001 16:08:05 GMT
Is there an intended reason for why the filter task works differently from
the properties task?  Presumably you'd want to do a lot of the same things
when defining filters, just that you'd want the values to apply to filtering
rather than to create properties.

The big reason I ask is that properties allows two big features that filters
don't. Namely, the ability to resolve chains and the ability to reference
environment variables.

Some background: we like to do configuration builds by defining base
properties files and specific files for each config.
 buildconfig.properties
 buildconfig-dev.properties
 buildconfig-qa.properties
 buildconfig-production.properties

build.xml imports the buildconfig.properties and
buildconfig-${config}.properties file.  We'd like to do something similar
for filters, e.g. filters.properties, filters-qa.properties, etc.  However,
the filters don't allow for resolving chains quite as nicely as the
properties do, e.g. bea.home = c:/bea and weblogic.home =
${bea.home}/wlserver6.

References seem to be resolved sometimes but it's pretty broken in general
and we have to end up loading the filtersfile as properties and then
manually setting filter tokens based on the property.  This can be quite a
hassle when working across multiple large projects, and I'd like to have our
developers not have to worry about all that.

I'd be happy to look into updating the code for filter and property to work
using the same base superclass and submitting that for ant 1.4, but I wanted
to make sure it's not going to be controversial before I do all that work.

Thanks for your feedback,

Tim Dawson
Chieft Software Architect
WAM!NET, Inc.

Mime
View raw message