DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21724>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21724

references are not passed by antcall





------- Additional Comments From [EMAIL PROTECTED]  2003-07-22 13:13 -------
Opps, sorry did not see the second copytest2 target - please
disregard it.

The problem is that the reference "foo" do not get passed to the
sub project, as at this stage the sub-project has parsed the
build file and has it's own "foo" reference.

The example demonstrates the issue in that the target "copytest"
sets the reference "foo" to the filter set that sets the token foo to
the value bar. It then antcall's copytest2 which uses the reference
"foo", but this reference points to a filterset that sets the token foo
to the value notbar (this reference is set in the target "copytest3").

Another example that shows the issue is:
<project name="test" default="copytest" basedir=".">

  <target name="copytest2">
    <copy file="copytest.in" toFile="copytest1.out" overwrite="true">
      <filterset refid="foo"/>
    </copy>
    <concat><path path="copytest1.out"/></concat>
  </target>

  <target name="copytest">
    <echo file="copytest.in">@@foo@@</echo>
    <property name="myvalue" value="this is a value"/>
    <filterset id="foo" begintoken="@@" endtoken="@@">
      <filter token="foo" value="${myvalue}"/>
    </filterset>
    <antcall target="copytest2" inheritrefs="true" inheritall="no"/>
    <copy file="copytest.in" toFile="copytest2.out" overwrite="true">
      <filterset refid="foo"/>
    </copy>
    <concat><path path="copytest2.out"/></concat>
  </target>

</project>

Giving the result:
copytest2:
     [copy] Copying 1 file to /home/preilly/proj/learning/ref
   [concat] ${myvalue}


     [copy] Copying 1 file to /home/preilly/proj/learning/ref
   [concat] this is a value

How to fix?
I do not know without losing backward compatibily (ie, do not
store the id at parse time) or by adding a new id attribute
that gets processed at run time (ant-id ?) or by doing something
clever.

The first would break a lot of script tasks, the second is
plain ugly and the third would be nice.

The current fix would solve the problem for most of the use-cases.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to