You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by Mike Deibler <md...@nocpulse.com> on 2000/09/08 05:53:28 UTC
Filter Tokens - set to last occurance?
Hello all,
I hope someone can shed some light on this problem.
I have a properties file that has three sections; one for development,
one for qa and one for production. Each section has the same properties
set, but with a different prefixes (dev, qa or prod). Including the
properties file and using each property is working well.
I pass in the build target that specifies which environment to build for.
Based on this, I execute one of three config targets:
dev_config
qa_config
prod_config
Each of these have several copy tasks that takes a .in file and creates a file
that has certain tokens replaced. For example:
<filter token="cookieDomain" value="${qa.cookieDomain}" />
<copyfile src="${session_config_file}.in"
dest="${session_config_file}"
filtering="yes" />
What I am seeing is that the filter tokens seem to be set to the value
where they apprear LAST in the xml file. Whether or not that target is
executed or not. Given the ording above, all filter tokens are set to
the 'prod' settings. I have checked the value="" values and they are
correct before AND after the copy/filter takes place.
This would seem to be opposite of the properties behavior which is to
set to the first occurance (parse time, not run time?).
Is this the correct behavior? Is it a bug? Is there anything else I can
do? Or do I have a bug in my files that I just haven't seen yet?
I'm using ant 1.1 (7/18/2000)
Thanks!
Mike
--
Mike Deibler
NocPulse, Inc.
1293 Mountain View-Alviso Road, Suite D
Sunnyvale, CA 94089
Re: Filter Tokens - set to last occurance?
Posted by Stefan Bodewig <bo...@bost.de>.
>>>>> "MD" == Mike Deibler <md...@nocpulse.com> writes:
MD> Hello all, I hope someone can shed some light on this problem.
Yes, <filter> is executed at parser time, not at runtime. Every
<filter> is executed, dependencies are not checked. The last occurece
for a given token wins.
This is going to change before the next release (to match the behavior
you - and almost anybody - expect).
Stefan