| "java.lang.ClassCastException: org.apache.tools.ant.types.Path " error after | "java.lang.ClassCastException: org.apache.tools.ant.types.Path " error after 2006-09-22 - By peter reilly
The follows triggers a bug similar to your description:
<project>
<macrodef name="bug">
<sequential>
<path id="b" path="."/>
</sequential>
</macrodef>
<script language="beanshell"/>
<bug/>
</project>
C:\work\learning\ref\macro.xml:8: java.lang.ClassCastException:
org.apache.tools.ant.types.Path cannot be cast to
org.apache.tools.ant.UnknownElement
I think that this could also be triggered by <ant>
Peter
On 9/22/06, Peter Reilly <peter.kitt.reilly@(protected)> wrote:
>
> This is a bug.
>
> Can you open a bug request for this please.
>
> Do you use the id tag ? (references) in macro definitions.
>
> The way references work at the moment could (I think)
> cause the symtoms you describe.
> see: http://issues.apache.org/bugzilla/show_bug.cgi?id=34458
> for an example.
>
> Please try to get a small build file/s that shows the problem.
> Peter
>
>
> On 9/22/06, David Corley (AT/LMI) <david.corley@(protected)> wrote:
> >
> > Beffling is the word. I'm pretty familiar with Ant, and this is the
> > first time I've seen such a low level error.
> >
> > The pre and post targets are filled with tasks of the end-users choice.
> > But for the example below and in the code that's causing the error, I
> > have just the one <echo> task in the pre target.
> >
> >
> > I should explain my reasoning for carrying things out the way I do.
> > Basically, I've defined a core build.xml for every developer on our
> > site. It allows them to only have to set their classpaths and
> > properties, and everything else will just work for them. So far it's
> > been quite succesful. But we came across a stumbling block where some
> > developers wanted to run tests against code they had just compiled.
> > Normally the developers would have stubs for their unit tests, but some
> > developers need to run against a live server. And the server code may
> > have just been compiled as part of the build.
> > Unfortunately the core build doesn't facilitate the running of any
> > compiled code, aside from the unit tests, which are run with the ant
> > <junit> task.
> >
> > So I came up with a workaround, where I allow the developers to do what
> > they like right before the unit testing starts and straight after it
> > finishes.
> > It means the core build.xml is still untampered, and the used get to run
> >
> > whatever <java> tasks need to be run before testing with their custom
> > junit-setup.xml targets. I suppose I could use <import>....but why
> > should I have to? The <ant> task should work just fine... No?
> >
> > My core Ant script is called with a -lib argument to include some extra
> > jars (javamail, junit, jaf), and I'm just wondering if they might cause
> > any problems.
> >
> > I'll get the developer experiencing the problem to change the code to
> > use an import statement and see how it goes.....but I still reckon
> > there's a bug somewhere in Ant....
> >
> > /Dave
> >
> >
> >
> > -----Original Message-----
> > From: Dominique Devienne [mailto: ddevienne@(protected)]
> > Sent: 22 September 2006 14:51
> > To: Ant Users List
> > Subject: Re: "java.lang.ClassCastException:
> > org.apache.tools.ant.types.Path" error after using <ant> task within ant
> >
> > > <target name="pre">
> > > <echo message="pre-junit"
> > > </target>
> > >
> > > <target name="post">
> > > </target>
> >
> > Hmmm, this is baffling indeed. Are the pre and post target above really
> > empty? If not, do they depend on any properties or references from the
> > main build you pass in thru <ant>? --DD
> >
> > PS: Note that your approach to this problem seems a bit wrong to me. I
> > would have used <import> rather than your combination of <ant> and
> > <antcall>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@(protected) For additional
> > commands, e-mail: user-help@(protected)
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@(protected)
> > For additional commands, e-mail: user-help@(protected)
> >
> >
>
|
|
 |
