> I was a bit confused with the behavior of dirname when the file
> property was that of an unset parameter.
> QUESTION: Is this a bug of feature?
It's a feature ;-) Or more precisely, it's the expected behavior...
> I suspect that the new File object gets constructed before calling
> setFile, so in my example ${foobar}.getParent() is equivalent to the
> current directory.
Well, it has to be. First, Ant evaluates the file XML attribute. It sees
${foobar} has the value, and notices it's a property reference. It
looks up the property, and replaces it (normaly), but since in your
case the property is not defined, Ant leave the XML value unchanged,
silently. It's a debatable behavior, but that's the Ant behavior for
sure.
> Seems like the right behavior would be to fail someway if the path
> named by dirname's file attribute didn't exist. Anyone else agree?
Well, yes and no. Sometimes you want to know the parent directory of
the file you haven't created yet, for example to create this parent
directory. File.getParent() doesn't need the File itself to exists to
return a meaningful result.
> Second question: I thought foobar.dir would be a relative path and
> <property location=...> would be the absolute path, but they're both
> the same. What am I missing??
No. When Ant converts an XML attribute to a File object, it always
resolves the value against the project's basedir. <property
location=...> called Property.setLocation(File), so the same
conversion applies as in Dirname.setFile(File). Internally Ant almost
always works with absolute paths. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
