ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mathieu Champlon <>
Subject Re: FileSet inside MacroDef causing ClassCastException
Date Wed, 23 Aug 2006 05:50:20 GMT
Hello !

Hari Krishna Dara a écrit :
> Can anyone provide any help in working around or fixing this problem?

It looks like the same bug as ?

> Here is the macro that causes trouble (I stripped the sequence to the
> least that causes theis problem, but as I said before, I couldn't copy
> this into a standalone build file and reproduce the exception):
>   <macrodef name="patchifmatches">
>       <attribute name="source"/>
>       <!-- See "target" on patchif -->
>       <attribute name="target"/>
>       <attribute name="windows" default="true"/>
>       <attribute name="solaris" default="true"/>
>       <element name="selection" implicit="true"/>
>       <sequential>
>           <fileset id="patchfileset" dir="${branch.path}">
>               <patternset refid="patch.filelist"/>
>               <selection/>
>           </fileset>
>       </sequential>
>   </macrodef>
> Here is the macro that is part of the same build file and works fine:
>   <macrodef name="checkIfComponentNeedsPatch">
>       <attribute name="componentName"/>
>       <element name="selection" implicit="true"/>
>       <sequential>
>           <!-- FIXME: How do I suppress the "override" warning
> message this generates -->
>           <fileset id="patchfileset" dir="${branch.path}">
>               <patternset refid="patch.filelist"/>
>               <selection/>
>           </fileset>
>           <pathconvert pathsep=" " 
> property="@{componentName}NeedsPatchTmp"
>               refid="patchfileset"/>
>           <condition property="@{componentName}NeedsPatch">
>               <not>
>                   <equals arg1="${@{componentName}NeedsPatchTmp}" 
> arg2=""/>
>               </not>
>           </condition>
>       </sequential>
>   </macrodef>
How are your macro called ? With what 'selection' ?
How many times each ? In which order ?
What happens when you remove the call to the 'working' one ? (I suspect 
it 'fixes' the other :p)

I'm not really surprised by the fact that it works fine when you copy 
your macros to a new build file, I had quite a lot of fun trying to 
reproduce the bug for the issue :)
Actually what happens is that the same element is used either in several 
macros or several times in the same macro. Then as it gets resolved (and 
so is not an unknown element anymore) upon first use, it is no longer an 
UnknownElement for the remaining calls...
I don't know if this makes sense, but anyway try and apply the patch and 
see if it fixes this issue for you ?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message