True Diane. I didn't think of all those other cases. It seems to me that Ant tasks should nonetheless attempt to strive for as much 'smarts' and convenience though. A lot of the other examples you cite could be handled by keeping state in between invocations, similar to the cache for example. It might not always be worth the trouble, but in this particular case, each file timestamp has to be checked against its source anyway, so adding the check against the filter file, if any, is both 'cheap' and 'useful'. If the filter is inline, in the build file, this can't be done without some kind of checksum of the filters, so it not done. If Ant could use the Preferences API from Java 1.4, it could actually be done somewhat easily though. Taking your argument the opposite way, should we remove the implicit out of ? Of course not. I take your point that it can't easily be added everywhere, but that doesn't mean it should be precluded. And finally, to come back on my gripe, if we do have to rely on other tasks to do this kind of explicit file dependencies, then why do we always have to fragment our builds into these small targets with complex dependencies setting properties instead of clean conditional execution!?!?!? I was told it's to avoid scripty builds, and that smarts should be built-in to the task, and you just shot me back that justification in the face. --DD -----Original Message----- From: Diane Holt [mailto:holtdl@yahoo.com] Sent: Monday, July 01, 2002 1:27 PM To: Ant Users List Subject: RE: testing for update on filter file --- Dominique Devienne wrote: > This works, but is more a work-around. The semantic of (its > 'smarts') is broken if the files are not copied when the filter file > has changed. But if you're going to have check for filter-file-newer, what about also checking for when 's are changed? Or 's? And are you going to offer the same for the 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 , , , , 's, etc. The task tries to cover that sort of thing, when an in-line 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 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. Diane ===== (holtdl@yahoo.com) __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- To unsubscribe, e-mail: For additional commands, e-mail: -- To unsubscribe, e-mail: For additional commands, e-mail: