But there is at least a quite nice workaround. You can turn a path into a
string and then back into a path in your called target:
<property "path.string" refid="path.reference"/>
----- Original Message -----
From: "Colin Sampaleanu" <[EMAIL PROTECTED]>
To: "Ant Developers List" <[EMAIL PROTECTED]>
Sent: Sunday, February 24, 2002 3:54 PM
Subject: bug: Ids from paths not propogated through antcalls unless path is
top-level
> Unless I am missing something, there is a bug in Ant 1.4.1 in that ids
> from path structures don't propogate (aren't usable) through antcalls,
> unless the path structure defining the id is top level. Consider the
> following ant script:
> -----
> <?xml version="1.0"?>
>
> <project default="main" basedir=".">
>
> <path id="id.path1">
> <pathelement path="build"/>
> </path>
>
> <target name="main">
> <echo message="entering main"/>
>
> <path id="id.path2">
> <pathelement path="build"/>
> </path>
> <property name="prop.path1" refid="id.path1"/>
> <echo message="prop.path1=${prop.path1}"/>
> <property name="prop.path2" refid="id.path2"/>
> <echo message="prop.path2=${prop.path2}"/>
>
> <antcall target="target1"/>
> </target>
>
> <target name="target1">
> <echo message="entering target2"/>
> <property name="prop2.path1" refid="id.path1"/>
> <echo message="prop2.path1=${prop2.path1}"/>
> <property name="prop2.path2" refid="id.path2"/>
> <echo message="prop2.path2=${prop2.path2}"/>
> </target>
>
> </project>
> ----
> On my system, running the main target generates the following output:
> ----
> Buildfile: build.xml
>
> main:
> [echo] entering main
> [echo] prop.path1=G:\temp\build
> [echo] prop.path2=G:\temp\build
>
> target1:
> [echo] entering target2
> [echo] prop2.path1=G:\temp\build
>
> BUILD FAILED
>
> G:\temp\build.xml:27: Reference id.path2 not found.
> ----
> The id from the first path, id.path1, which is defined in the top-level
> section, is available both in the initial and the called target. When I
> define a path, id.path2, that id is available only in the initial
> target, and not in the called target.
>
> This bug is extremely nasty for me, since instead of defining all my
> paths at the top level like most people seem to do, I need to define
> some paths in one of my init targets, after I have conditionally read in
> one or another property file. This bug effectively stumps me.
>
> Am I missing something?
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
