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}"
overwrite="true"
verbose="${copy.verbose.flag}">
<fileset dir="${resouce.dir}">
<include name="**/*.template"/>
</fileset>
<mapper type="glob"
from="*.template" to="*"/>
<filterset begintoken="@" endtoken="@">
<filtersfile file="${deploy.properties.file}"/>
</filterset>
</copy>
(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
deploy.properties 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<pon...@hotmail.com> 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.qa, db.connections.uat, web.xml.qa,
> web.xml.dev, 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.
> http://windowslive.com/Tutorial/Hotmail/Storage?ocid=TXT_TAGLM_WL_HM_Tutorial_Storage_062009
--
David Weintraub
qazw...@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@ant.apache.org
For additional commands, e-mail: user-h...@ant.apache.org
