>>>>> "VR" == Vassilis Rizopoulos <[EMAIL PROTECTED]> writes:
VR> Is there a particular reasoning behind having <available>
VR> evaluated on a global scale in the build file?
Well the most obvious reason, and one we are going to change, is that
${} replacement happens while parsing the buildfile. If you were ever
going to use ${pack.present} the available task had better been
evaluated before the parser reached that line.
You are perfectly right about the limitations this causes.
But be assured that this is going to change - just don't ask when,
please.
BTW your could code your example without the if attribute on the target
pack client like this
<target name="pack.client" depends="pack.general">
<copydir src="${basedir}/config/pack" dest="${pack.home}">
<exclude name="**/*" unless="pack.present">
</copydir>
</target>
I know that the nested include/exclude haven't been documented for a
long time - I think the first mention of them in official docs has
been introduced yesterday.
VR> And another thing: I noticed that the <javac> task does not
VR> handle correctly \ and / as path separators when supplied in the
VR> classpath attribute setting the classpath to c:/jdk/bla/bla does
VR> not work correctly, while c:\\jdk\\bla\\bla works fine.
Yes, that is because c:/jdk could be a path consisting of two parts, c
and /jdk on Unix.
VR> I've got the binaries of version 1.0.8 installed.
Oops, whatever that may be. Sam?
Anyway, several problems have been resolved recently so you might want
to take a look at one of the nightly builds or retrieve the current
sources from CVS.
Stefan
