ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Hatcher" <>
Subject Re: Filter task w/ properties file
Date Tue, 11 Sep 2001 21:53:50 GMT
Agreed.   I don't really see a reason for your need to move the dynamic
property-based filters to a properties file though.  Seems like a 6-of-one,
half-dozen of the other kind of argument.


----- Original Message -----
From: "Timothy Shadel" <>
To: <>
Sent: Tuesday, September 11, 2001 1:52 PM
Subject: Re: Filter task w/ properties file

Yeah, but then I'm right back to listing the properties directly in the
build.xml.  The only difference is that I'd use <entry> tags under the
<propertyfile> instead of <filter> tags anywhere.

- Tim

>>> "Erik Hatcher" <> 09/11/01 02:12PM >>>
You could use <propertyfile> to write your properties to a file, then read
them in using <filter> as a workaround.


----- Original Message -----
From: "Timothy Shadel" <>
To: <>
Sent: Tuesday, September 11, 2001 12:50 PM
Subject: Filter task w/ properties file

I want to replace these lines in my build.xml :

<filter token="VERSION_MAJOR" value="${version.major}" />
<filter token="VERSION_MINOR" value="${version.minor}" />
<filter token="BUILD_NUMBER" value="${version.buildnum}" />

with a file ( like this:


and place this in my build.xml:

<filter filtersfile="" />

But the problem is that the Filter task (more specifically the FilterSet
object to which it delegates file loading) doesn't replace the ${} property
references with the project's values for those properties.  Instead it
leaves the full string and ${} in when it filters the files during copy.

If I can pull similar filters out of my build file I believe that would
definitely make it MORE readable, but it's not worth it if I can't have
access to the project's properties.  Is there a particular reason it's not
done this way, and a workaround to accomplish the same thing?  Or has it
just not made it in to the feature set yet?



View raw message