ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothy Shadel <shade...@mtc.byu.edu>
Subject Re: Filter task w/ properties file
Date Tue, 11 Sep 2001 22:19:53 GMT
It's more to make build files that are generic enough to be used for several of our projects,
and allow each project to use property files to maintain project-specific info like version
and build numbers.

- Tim

>>> "Erik Hatcher" <jakarta-ant@ehatchersolutions.com> 09/11/01 03:53PM >>>
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.

    Erik


----- Original Message -----
From: "Timothy Shadel" <shadeltd@mtc.byu.edu>
To: <ant-user@jakarta.apache.org>
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" <jakarta-ant@ehatchersolutions.com> 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.

    Erik


----- Original Message -----
From: "Timothy Shadel" <shadeltd@mtc.byu.edu>
To: <ant-user@jakarta.apache.org>
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 (filter.properties) like this:

VERSION_MAJOR=${version.major}
VERSION_MINOR=${version.minor}
BUILD_NUMBER=${version.buildnum}

and place this in my build.xml:

<filter filtersfile="filter.properties" />

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?

Thanks,

Tim








Mime
View raw message