in a copy task Filtering does not take place if filter value has changed

[Jérôme Lacoste <je...@smartcardsystem.com>]

If you modify the build.xml and change the value of the filter task, the
filtering does not happen.
In fact copy only checks the time of the files to copy.

Is this a normal behavior? or should it be documented?

The problem happens with other tasks as well.
Should these tasks be aware of the last modification time of the build.xml
file ?

Jerome

Note: I am not running the latest build, but something between Ant 1.3 and
now.

Re: in a copy task Filtering does not take place if filter value has changed

[Diane Holt <ho...@yahoo.com>]

--- Stefan Bodewig <bo...@apache.org> wrote:
> On Thu, 5 Jul 2001, Jirtme Lacoste
> <je...@smartcardsystem.com> wrote:
> 
> > If you modify the build.xml and change the value of the filter task,
> > the filtering does not happen.  In fact copy only checks the time of
> > the files to copy.
> 
> Yes, this is the expected behavior and the standard workaround is to
> use the overwrite attribute of copy, this is what we do in Ant's build
> file for the version information ourselves.
>
> [snip] 
> 
> The coloring approach Peter describes looks as the only clean
> solution, but I don't see anything like this in the nearer future.
> Up to then we have to rely on the build-meister to know when things
> have changed that need manual intervention (like setting the overwrite
> attribute or running a clean target before building).

If you define your filters in a properties file, couldn't you make the
target that does the copying depend on the up-to-dated-ness of that/those
file(s)?

Diane

=====
(holtdl@yahoo.com)



__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

Re: in a copy task Filtering does not take place if filter value has changed

[Stefan Bodewig <bo...@apache.org>]

On Thu, 5 Jul 2001, Jirtme Lacoste
<je...@smartcardsystem.com> wrote:

> If you modify the build.xml and change the value of the filter task,
> the filtering does not happen.  In fact copy only checks the time of
> the files to copy.

Yes, this is the expected behavior and the standard workaround is to
use the overwrite attribute of copy, this is what we do in Ant's build
file for the version information ourselves.

> The problem happens with other tasks as well.  Should these tasks be
> aware of the last modification time of the build.xml file ?

I don't think so, as it would lead to a lot of unnecessary actions.
Say we make the javac task aware of the build files last modification
time (the value of the debug attribute could have changed), then you'd
always recompile all classes when you touch the build file.

The coloring approach Peter describes looks as the only clean
solution, but I don't see anything like this in the nearer future.
Up to then we have to rely on the build-meister to know when things
have changed that need manual intervention (like setting the overwrite
attribute or running a clean target before building).

Stefan

Re: in a copy task Filtering does not take place if filter value has changed

[Peter Donald <do...@apache.org>]

On Fri,  6 Jul 2001 02:00, Jérôme Lacoste wrote:
> If you modify the build.xml and change the value of the filter task, the
> filtering does not happen.
> In fact copy only checks the time of the files to copy.
>
> Is this a normal behavior? 

yep.

> or should it be documented?

yep ;)

> The problem happens with other tasks as well.
> Should these tasks be aware of the last modification time of the build.xml
> file ?

maybe. The only real solution I know is one that has been suggested a few 
times before. This is the notion of "coloring" operations. ie In this case 
the copy task would be "colored" by the tokens used in copy operation. If the 
tokens changed it would be "colored" differently. This color information 
(along with file dependencies) is then stored in some other location (ie a 
dependency cache). If color changes or other dependency information changes 
the operation (ie copy) is executed.

This is the strategy used by a few tools (cons being the prime example IIRC). 
However to actually implement this in ant would require a large amount of 
work which no one has got around to yet ;)

Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*