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 21:00:36 GMT
--- Dominique Devienne <> wrote:
> A lot of the other examples you cite could be handled by keeping state
> in between invocations,

I save state in (generated) properties files, then do checks on their
current value vs. their previous value. In the old days, when I had a
modified <target>, I did it with, eg:
  <target name="doSomething" unless="${foo}=${bar}"/>
Nowadays, in order to avoid having to have a modified Ant, I'd do it using
<condition>/<equals>, then test on the prop that <condition> set/didn't
set -- but I still prefer the earlier way.

> I take your point that it can't easily be added everywhere, but that
> doesn't mean it should be precluded.

Except that then you get into having yet more to learn and remember about
which tasks do what for you, and which don't. And not just for the person
who writes the Ant files, but for the people who just run them as well --
and that's where I think it could lend itself to being confusing (and
potentially risky [ie., bogus build results]), unless the behaviour was
consistent across tasks, and for all (or at least most) contingencies.

> 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.

That's because I'm one of the people who agrees with you :)  I'm not
against "scriptiness" at all. In fact, I think not allowing for it
actually makes Ant more difficult to use. When I put together a build
process, I want it to be as straightforward as possible for the people who
have to use it directly -- ie., developers who run it over and over all
day. Ideally, all they should ever need to do is run 'tool-name'. That's
not always going to be possible, since there'll likely always be some
additional things they need to learn about and make sure they do to get
the results they're after -- but the fewer of those things, the better. To
achieve that could (and more often than not usually does) mean having a
fair amount of complexity "under the covers" -- but that's okay, since the
end result is that then the users of the process don't have to deal with
those things.

Of course, if you can make it so it's simple from both sides, all the
better -- but I'm not sure adding certain "convenience" functionality to
some tasks and not others would necessarily be moving in that direction.
As it is now, there's not as much consistency between tasks (even just for
things like names for attributes that mean the same thing) as there should
be, so introducing inconsistent behaviour between similar tasks (eg.,
<copy> and <replace>) seems like it'd only lead to additional confusion.



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

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

View raw message