>
> "Ant Way" of doing what you want is to use the copy task and then use the
> and sub-tasks to modify your copying.
>
Dumb me!
I am *insisting* on the use of ${build.property} style patterns in my files
and getting rid of doing the replace at all!! Makes sense?
Cheers
Avlesh
On Wed, May 27,
"Ant Way" of doing what you want is to use the copy task and then use
the and sub-tasks to modify your copying.
You right now build the warfile in place, and copying all the files to
another directory will increase your build time by a minute or two.
However, it will eliminate the CVS polling is
>
> You mentioned something about having to restore versioned files once
> the substitution is done. We don't have to do that because we don't
> touch the directories where the files are versioned. Instead, we copy
> all the files out to our "target" directory.
>
Right, I do restore the original v
On Tue, May 26, 2009 at 1:29 PM, Avlesh Singh wrote:
> My approach is very similar to yours, David.
> Would it make sense to have something like an injectBuildProperties task in
> ant?
You mentioned something about having to restore versioned files once
the substitution is done. We don't have to
My approach is very similar to yours, David.
Would it make sense to have something like an injectBuildProperties task in
ant?
Cheers
Avlesh
On Tue, May 26, 2009 at 10:44 PM, David Weintraub wrote:
> We do something similar. However, all build files we produce are
> placed in a target directory
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
