You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by Dominique Devienne <DD...@lgc.com> on 2002/07/01 18:54:12 UTC
RE: testing for update on filter file
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. It
should be built-in to <copy> IMHO, and avoid doing the depends/if dance. I
think this is my single real gripe about Ant, all these convolutions one has
to go thru to perform something conditionally when it's not built-in to the
task itself. --DD
-----Original Message-----
From: Jon Skeet [mailto:jon.skeet@peramon.com]
Sent: Friday, June 28, 2002 9:24 AM
To: Ant Users List
Subject: RE: testing for update on filter file
> I'm using the copy task in conjunction with an external
> filter file. I
> understand that if copy task detects if one of the source
> files is newer
> than the target file, it will copy the source file to the
> target, otherwise
> it will not copy the source file.
>
> What I'm looking to do is trigger a copy of the source files, based on
> whether my filter file changed. In other words, even if my
> source files haven't changed, if something in the file filter changes, I
> want the source files to be re-parsed with the tokens in the filter file
and
> copied to the target directories.
>
> How do I detect that the filter file has changed and how do I
> subsequently trigger a copy on the source files?
Use the uptodate task to check whether the destination files are more recent
than all of your source files *and* your filter file, and set a property if
so. Then only execute the filter if the property isn't set.
Jon
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: testing for update on filter file
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
----- Original Message -----
From: "Erik Hatcher" <ja...@ehatchersolutions.com>
To: "Ant Users List" <an...@jakarta.apache.org>
Sent: Monday, July 01, 2002 1:02 PM
Subject: Re: testing for update on filter file
> For what its worth, I agree completely with Dominique's remarks about
> filtered <copy> (and in general, on the topic of dependency checking).
>
> Ant is only as good as its smarts under the covers of these tasks.
>
> So, DD, gonna send us a path for the copy task? :))
I meant "patch".
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: testing for update on filter file
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
For what its worth, I agree completely with Dominique's remarks about
filtered <copy> (and in general, on the topic of dependency checking).
Ant is only as good as its smarts under the covers of these tasks.
So, DD, gonna send us a path for the copy task? :))
Erik
----- Original Message -----
From: "Dominique Devienne" <DD...@lgc.com>
To: "'Ant Users List'" <an...@jakarta.apache.org>
Sent: Monday, July 01, 2002 12:54 PM
Subject: RE: testing for update on filter file
> 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. It
> should be built-in to <copy> IMHO, and avoid doing the depends/if dance. I
> think this is my single real gripe about Ant, all these convolutions one
has
> to go thru to perform something conditionally when it's not built-in to
the
> task itself. --DD
>
> -----Original Message-----
> From: Jon Skeet [mailto:jon.skeet@peramon.com]
> Sent: Friday, June 28, 2002 9:24 AM
> To: Ant Users List
> Subject: RE: testing for update on filter file
>
> > I'm using the copy task in conjunction with an external
> > filter file. I
> > understand that if copy task detects if one of the source
> > files is newer
> > than the target file, it will copy the source file to the
> > target, otherwise
> > it will not copy the source file.
> >
> > What I'm looking to do is trigger a copy of the source files, based on
> > whether my filter file changed. In other words, even if my
> > source files haven't changed, if something in the file filter changes, I
> > want the source files to be re-parsed with the tokens in the filter file
> and
> > copied to the target directories.
> >
> > How do I detect that the filter file has changed and how do I
> > subsequently trigger a copy on the source files?
>
> Use the uptodate task to check whether the destination files are more
recent
> than all of your source files *and* your filter file, and set a property
if
> so. Then only execute the filter if the property isn't set.
>
> Jon
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: testing for update on filter file
Posted by Diane Holt <ho...@yahoo.com>.
--- Erik Hatcher <ja...@ehatchersolutions.com> wrote:
> It is indeed a tough issue. All it takes is one property to change for
> all dependency checking to go out the window (-Dbuild.debug=off, for
> example).
>
> But the more smarts we add, the better Ant is.
Well, yes and no. "Better" in the sense of less things for the build
writer to have to explicitly take care of themself -- but not really
better in the sense that then you have to remember which tasks check for
what, beyond the source-file -> target-file dependency checking. And that
brings me around to Dominique's reply, which I'll respond to there.
> When in doubt, run a clean build anyway! :))
For things like nightly and release builds, of course -- but not always
practical/desirable for developer builds, which occur far more often, so
the build should really be optimized for that. There are things people
know that, if they change, they should in fact to a clean build -- but the
more of those you introduce, and that they then have to remember, the less
optimal things get.
Diane
=====
(holtdl@yahoo.com)
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: testing for update on filter file
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
----- Original Message -----
From: "Diane Holt" <ho...@yahoo.com>
> 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, etc.
It is indeed a tough issue. All it takes is one property to change for all
dependency checking to go out the window (-Dbuild.debug=off, for example).
But the more smarts we add, the better Ant is.
When in doubt, run a clean build anyway! :))
Erik
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: testing for update on filter file
Posted by Diane Holt <ho...@yahoo.com>.
--- Dominique Devienne <DD...@lgc.com> 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, etc.
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.
Diane
=====
(holtdl@yahoo.com)
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>