ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Diane Holt <>
Subject RE: testing for update on filter file
Date Mon, 01 Jul 2002 18:27:16 GMT
--- Dominique Devienne <> wrote:
> This works, but is more a work-around. The semantic of <copy> (its
> 'smarts') is broken if the files are not copied when the filter file
> has changed.

But if you're going to have <copy> check for filter-file-newer, what about
also checking for when <filterset>'s are changed? Or <filterchain>'s?

And are you going to offer the same for the <replace> task, for its
'propertyfile' and 'replacefilterfile'? 

I think it basically boils down to the fact that, unlike most build tools,
where you can directly say fileA depends on fileB, in Ant, the way to
associate those sorts of explicit file dependencies is to use tasks such
as <uptodate>, <available>, <depend>, <dependset>, <selector>'s,

The <jar> task tries to cover that sort of thing, when an in-line
<manifest> is used, by checking whether the build file is newer than the
jar -- but, according to the doc, it doesn't "take into account property
file changes which may affect the resulting jar". (It also doesn't say
whether it goes on to check whether the specified manifest entries are
what actually changed in the build file or whether it just does a simple
timestamp check, which, if that's case, could end up rebuilding the jar
for no real reason, since the build file change could be completely
unrelated to the <jar> task). So I think you're kind of opening up a small
can of worms when you start trying to implement some tasks to do some
additional checking, but not all tasks, and not all checking.



Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup

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

View raw message