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