We do something similar. However, all build files we produce are
placed in a target directory (much like Maven does). This makes it
easy to clean up after a build because we only need to delete a single
directory.
As part of our build process, we also have to do parameter
replacements. We do this by having the files that need these
replacements have a suffix of *.template added on to the end.
We then use the <copy> task to copy the files over. We do this in two
steps. The first copies the files over, but skips all *.template
files. The next <copy> task now copies over the *.template files.
We use a <glob> mapper to remove the *.template suffix and a <filters>
and <filtersfile> to do the filtering during the <copy> task:
<!-- Copy the configuration files that don't contain tokens -->
<copy todir="${target.dir}/work"
verbose="${copy.verbose.flag}">
<fileset dir="${src.dir}/main/resources">
<exclude name="**/*.template"/>
</fileset>
</copy>
<!-- Copy the configurable files and replace any tokens -->
<copy todir="${target.dir}/work"
overwrite="true"
verbose="${copy.verbose.flag}">
<fileset dir="${src.dir}/main/resource">
<include name="**/*.template"/>
</fileset>
<mapper type="glob"
from="*.template" to="*"/>
<filterset begintoken="@" endtoken="@">
<filtersfile file="${deploy.properties.file}"/>
</filterset>
</copy>
On Tue, May 26, 2009 at 12:36 PM, Avlesh Singh <avl...@gmail.com> wrote:
> I am dealing with a web application which has a huge list of build
> parameters. This list ranges from multiple data sources, to REST based API
> Url's, to HTTP connection properties ... I need to replace these values at
> build time in several confugiration/properties files residing in the
> applications classpath. To name a few - Hibernate property files, Spring
> property files etc.
> Currently, I am accomplising this by having replacable tokens (e.g
> _build.property_) in the above mentioned files. As a part of the build
> process (mostly the "war" target), I replace these tokens (using the
> replaceToken task) with their corresponding build property values. The only
> unfortunate part about all this is that my build.xml file looks horrible,
> mostly because, the files that I modified, need to be restored back to their
> original state. Only the distribution war for the application is desired to
> have those replaced values.
>
> I have a few questions:
>
> 1. Is there a better way of achieving this?
> 2. If no, is a wrapper task worth an ant contribution? I am basically
> talking about a task which, given a fileset, would replace all occurences of
> ${build.property} in those files.
>
> Cheers
> Avlesh
>
--
David Weintraub
qazw...@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@ant.apache.org
For additional commands, e-mail: user-h...@ant.apache.org
