A tale of stupid defaults

[Andreas Krey <a....@gmx.de>]

<ivy:import>
<copy tofile="whatever.sub">
  <fileset dir="lib" includes="whatever*.suf"/>
</copy>
<exec executable="whatever-compiler">
  <arg value="whatever.suf">
</exec>

**
 
"That version of whatever doesn't have the feature needed."

"Then just change the requirement in ivy.xml and rebuild"

"The copy fails."

"Oh yeah. Ivy doesn't remove stuff that it would fetch anymore.
It just leaves it there. You need to remove 'lib' beforehand."

"Ouch. Why not. Ok." Half a minute. "It fetched the new stuff,
it doesn't report failure, but it's still not working. Why?"

"Umm." Headscratch. 

**

Well, it turns out that ivy has the habit of delivering files with the
timestamp they have in the repository. Unfortunately the copy task has
the habit of not copying if the destination file is newer that the source,
which means that whatever.suf wasn't copied even though the source wasn't
there a second ago.

And the build 'succeeded' because the exec task has the habit of not
making the build terminate if it's invocation returns a failure.

How utterly stupid are these defaults? And why haven't they ever been
changed? Backward-compatibility isn't an argument; these defaults are
simply insane (as defaults), and everybody else around demonstrates how
one can migrate away from defaults that seemes plausible some time ago.

And I can't imagine how failonerror=false ever seemed sensible,
except for 'we need to do it different from make'.

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org