ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hari Krishna Dara" <harid...@gmail.com>
Subject Re: FileSet inside MacroDef causing ClassCastException
Date Thu, 24 Aug 2006 01:56:45 GMT
> ---------- Forwarded message ----------
> From: "Peter Reilly" <peter.kitt.reilly@gmail.com>
> To: "Ant Developers List" <dev@ant.apache.org>
> Date: Wed, 23 Aug 2006 23:26:09 +0100
> Subject: Re: FileSet inside MacroDef causing ClassCastException
> This is a different problem to MATs.
> This problem is due to the resolution of references.
> The build script can be reduced to:
>
> <project>
>   <macrodef name="my-macrodef">
>     <sequential>
>       <fileset id="fs" dir="."/>
>     </sequential>
>   </macrodef>
>
>     <script language="beanshell"/>
>
>     <my-macrodef/>
>
> </project>
>
> When the script task is executed, it converts all
> ant references to script variables (yuck). Ant references
> are set at parse time (double yuck) and so the "fs"
> reference will be resolved, this resolution converts the UnknownElement
> to a "real" object (triple yuck) which causes the bug.
> The last behaviour could be modified - but it is tricky
> code and it is difficult to modify without causing more bugs
> and backward compatibly problems.
>
> Peter
>

Thanks Peter. Your simpler test case is more reliable than mine for
reproducing the problem. As a workaround, I have put a condition
around addBean() method to ignore anything except "project"
(conditional to a System property), which is the only thing I am using
from the scripts. I will internally document to have the system
property set before running this build script, and I hope that this
bug will some day be fixed. I appreciate your help in location the
problem area.

PS: I can report this as a bug on the bugzilla with your testcase if
you haven't already done so.

>
> On 8/23/06, Hari Krishna Dara <haridara@gmail.com> wrote:
> >
> > Here is a simpler test case, that removes some ambiguities. As you can
> > see the content of the script task doesn't matter.
> >
> > <?xml version="1.0"?>
> > <project name="nested_macrodef_generates_class_cast_exception_modified"
> > default="test">
> >
> >     <macrodef name="patchif">
> >         <sequential>
> >             <echo message="I am patchif macro"/>
> >             <script language="beanshell"><![CDATA[
> >             ]]></script>
> >         </sequential>
> >     </macrodef>
> >
> >     <macrodef name="my-macrodef">
> >         <element name="elements"/>
> >         <element name="selection"/>
> >         <sequential>
> >             <fileset id="fs" dir=".">
> >                 <selection/>
> >             </fileset>
> >             <elements/>
> >         </sequential>
> >     </macrodef>
> >
> >     <target name="test">
> >         <patchif/>
> >
> >         <my-macrodef>
> >             <elements>
> >                 <echo>Test !!</echo>
> >             </elements>
> >             <selection>
> >                 <filename name="xxx"/>
> >             </selection>
> >         </my-macrodef>
> >     </target>
> >
> > </project>
> >
> >
> >
> > On 8/23/06, Hari Krishna Dara <haridara@gmail.com> wrote:
> > > > From: Mathieu Champlon <m.champlon@free.fr>
> > > > To: Ant Developers List <dev@ant.apache.org>
> > > > Date: Wed, 23 Aug 2006 14:50:20 +0900
> > > > Subject: Re: FileSet inside MacroDef causing ClassCastException
> > > > 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
> > > > http://issues.apache.org/bugzilla/show_bug.cgi?id=40238 ?
> > > >
> > > > > 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 ?
> > > >
> > > > MAT.
> > >
> > > I tried the patch suggested in the bug report on 1.6.2, but that
> > > didn't solve the problem. So I applied the patch to 1.6.5 version, but
> > > still I got the same exception. However, I was able to verify that the
> > > patch fixes the testcase that you attached (by running before and
> > > after applying the patch).
> > >
> > > Just like you guessed, if I comment the lines that are working, the
> > > next two calls to this macro including the one that was failing
> > > before, go through fine. This probably indicates that the problem you
> > > reported and this are related, but there is still another case that is
> > > not taken care of?
> > >
> > > Based upon your test case, and more trial and error of carefully
> > > commenting parts of the code, I narrowed down the macrodef's that are
> > > causing this problem. I am pasting a reproducible test case below, but
> > > it requires BeanShell/BSF jar files to be present in the classpath/ant
> > > lib directory (bsf.jar, bsh-2.0b4.jar and bsh-bsf-2.0b4.jar). Can
> > > anyone please take a look at this test case and give any guidance on
> > > how to find and fix the problem?
> > >
> > > PS: If anyone wants, I can send the above 3 jar files by email to make
> > > it easier for you to run the below testcase.
> > >
> > > Thank you,
> > > Hari
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> > For additional commands, e-mail: dev-help@ant.apache.org
> >
> >
>
>
>

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


Mime
View raw message