ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominique Devienne <>
Subject RE: testing for update on filter file
Date Mon, 01 Jul 2002 19:02:31 GMT
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 <depend> 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
<uptodate> out of <javac>? 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.


-----Original Message-----
From: Diane Holt [] 
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 <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: <>

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

View raw message