DO NOT REPLY [Bug 47119] New: properties not expanded in default attributes

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=47119

           Summary: properties not expanded in default attributes
           Product: Ant
           Version: 1.7.0
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Core tasks
        AssignedTo: notifications@ant.apache.org
        ReportedBy: vladimir_egorov@yahoo.com


Reproducer:

    <macrodef name="echotest">
      <attribute name="foo" default="${foo}" />
      <attribute name="bar" default="${@{foo}}" />
      <sequential>
        <echo message="foo is [@{foo}]" />
        <echo message="bar is [@{bar}]" />
      </sequential>
    </macrodef>

    <property name="foo" value="bar" />
    <property name="bar" value="baz" />

    <echotest />

Output:

     [echo] foo is [bar]
     [echo] bar is [${${foo}}]           --> bug, expect 'bar is [baz]'

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 47119] properties not expanded in default attributes

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=47119

Mounir <me...@murex.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |melhaj@murex.com

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 47119] properties not expanded in default attributes

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=47119





--- Comment #1 from Vladimir Egorov <vl...@yahoo.com>  2009-04-29 15:55:47 PST ---
Suggested fix:

add the following line

      value = getProject().replaceProperties(value);

at line 343 org/apache/tools/ant/taskdefs/MacroInstance.java (the line number
is from 1.6.5 source). The surrounding code looks like this:

      ...
      if (value == null) {
        throw new BuildException("required attribute " + attribute.getName()
            + " not set");
      }
      value = getProject().replaceProperties(value);
      localProperties.put(attribute.getName(), value);
      copyKeys.remove(attribute.getName());
      ...

If I can get permission, I can make the change and add tests.

--Vladimir

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 47119] properties not expanded in default attributes

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=47119





--- Comment #2 from Peter Reilly <pe...@apache.org>  2009-04-30 00:49:17 PST ---
properties do get resolved;
<project>
  <property name="x" value="this is x"/>
  <macrodef name="run">
    <attribute name="a" default="${x}"/>
    <sequential>
      <echo>a is @{a}</echo>
    </sequential>
  </macrodef>
  <run/>
</project>

i.e. they get resolve at the time of macro declaration,
but not at the time of macro use.

I am not sure that it is a good idea to resolve them
again at run time.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 47119] properties not expanded in default attributes

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=47119





--- Comment #3 from Vladimir Egorov <vl...@yahoo.com>  2009-04-30 09:27:08 PST ---
Thanks for your review. Yes, properties do get replaced at macro declaration
time. This request is to also replace them at macro call time.

Note that currently, the behavior is inconsistent: property in foo attribute
got replaced, but not in bar.

I would think that expression like ${${foo}} is most likely not what user had
intended. Is there any reason to want this?

This limitation keeps coming up in our framework. We like to use macrodef'
feature of providing defaults for attributes in terms of previously defined
attributes. But this breaks down, unexpectedly, when we try to use properties.
Our users are telling us that we should fix this in the framework.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.