bug of feature?

[Cyril Sagan <cy...@unx.sas.com>]

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?

Here's my full example:
$ cd /tmp/Ant_Mystery
$ ant  -version
Apache Ant version 1.6.5 compiled on June 2 2005

$ cat build.xml
<?xml version="1.0"?>
<project name="Ant_Mystery">
    <!-- Illustrate some mysteries with <dirname> task -->
    <dirname property="foobar.dir" file="${foobar}" />
    <property name="foobar.fullpath" location="${foobar.dir}"/>
    <echo>
        foobar = ${foobar}
        foobar.dir = ${foobar.dir}
        foobar.fullpath = ${foobar.fullpath}
    </echo>
</project>

$ ant
Buildfile: build.xml
     [echo] 
     [echo]         foobar = ${foobar}
     [echo]         foobar.dir = /tmp/Ant_Mystery
     [echo]         foobar.fullpath = /tmp/Ant_Mystery
     [echo]     

BUILD SUCCESSFUL
Total time: 1 second


I wouldn't expect the foobar.dir property to be set since the file
attribute comes from an unset property.  From the ant source code, I
think I see why this is happening:

from main/org/apache/tools/ant/taskdefs/Dirname.java:
    public void setFile(File file) {
        this.file = file;
    }

    // The method executing the task
    public void execute() throws BuildException {
...
        if (file == null) {
            throw new BuildException("file attribute required", getLocation());
        } else {
            String value = file.getParent();
            getProject().setNewProperty(property, value);
        }
    }


I suspect that the new File object gets constructed before calling
setFile, so in my example ${foobar}.getParent() is equivalent to the
current directory.

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?

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

I'd appreciate hearing other comments.  Thanks.

--Cyril

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

Re: bug of feature?

[Dominique Devienne <dd...@gmail.com>]

> 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: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org