ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Weintraub <>
Subject Re: Tokenizing Property Files
Date Thu, 25 Jun 2009 16:12:10 GMT
If all of these files agree EXCEPT for these specific values, then you
should use filtering in your build.xml when you copy these files to
build your artifacts.

This (fortunately) is pretty simple to do:

   <copy todir="${deploy.dir}"
        <fileset dir="${resouce.dir}">
             <include name="**/*.template"/>
        <mapper type="glob"
             from="*.template" to="*"/>
        <filterset begintoken="@" endtoken="@">
            <filtersfile file="${}"/>

(In our situation, the files that are filtered have a "*.template"
suffix on them, thus we need the <mapper> to remove this suffix from
our files).

This way, all of the values can be stored in separate files which you can specify on the command line.

The advantage is quite simple: You only have to maintain a single set
of files. Imagine if one of these XML files changed. Right now, you
would have to duplicate this one change in all environments. This way,
you only have to modify the template file itself.

Plus, if you create another environment, you only have to create a new
properties file for that environment and not duplicate everything.
Also, if something changes (like a password), in your system, you have
to comb through all the files to make sure it wasn't specified in more
than one place. Using filtering, you only have to change it in the
deploy properties file for that environment.

And, you can have a common deploy properties file and individual
deploy properties file. That way, something that is the same value in
all of those environments is changed (such as your test server IP
address), you only have to modify the common deploy properties and not
the individual ones.

On Wed, Jun 24, 2009 at 7:10 PM, Rez P<> wrote:
> What's the right way to use token replacement for my Ant builds?
> We have a few files common to all environments and currently maintain a set of these
files per environment -- xml files, property files, and a web.xml per environment not identical.
 The files contain mostly static information except such variables as the urls or db connection
and usrid/pw which change per environment.  Currently we retain a few sets of these files
per environment, e.g., db.connections.uat,,, etc
& their corresponding ant value in build.xml would be db.connections.${env}, where env
equals qa, dev,  etc, and then I pass the qa or uat  parameters to the build.xml during
the Ant compile process as -Denv=qa and generate a war file with their corresponding property
files and web.xml per environment.
> Would it be better, for the sake of automation consistency or cleanliness, for files
whose values do vary per environment, to come up with one base or master file, such as db.connections
or web.xml, and some of the values in each file which change for each environment to have
token values @UID@ or @PASSWORD@, etc. And each master file has 3 or 4 environment related
property files holding the actual values?
> What's the best way to address this issue?
> Thanks
> _________________________________________________________________
> Hotmail® has ever-growing storage! Don’t worry about storage limits.

David Weintraub

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message