You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bsf-dev@jakarta.apache.org by Stefan Bodewig <bo...@apache.org> on 2003/07/03 14:28:38 UTC
[GUMP] Build Failure - jakarta-bsf
----------------------------------------------------
This email is autogenerated from the output from:
<http://cvs.apache.org/builds/gump/2003-07-03/jakarta-bsf.html>
----------------------------------------------------
Buildfile: build.xml
init:
prepare:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-bsf/build
checkDependencies:
checkJacl:
[echo] Warning: Jacl dependencies were not resolved.
checkJPython:
[echo] Warning: JPython dependencies were not resolved.
checkJython:
checkNetRexx:
[echo] Warning: NetRexx dependencies were not resolved.
checkRhino:
checkXalan:
compile:
[copy] Copying 1 file to /home/rubys/jakarta/jakarta-bsf/build/classes
[javac] Compiling 51 source files to /home/rubys/jakarta/jakarta-bsf/build/classes
[javac] /home/rubys/jakarta/jakarta-bsf/src/org/apache/bsf/engines/javascript/JavaScriptEngine.java:194: cannot resolve symbol
[javac] symbol : method unwrap ()
[javac] location: class org.mozilla.javascript.WrappedException
[javac] t = (Throwable) ((WrappedException) t).unwrap();
[javac] ^
[javac] 1 error
BUILD FAILED
/home/rubys/jakarta/jakarta-bsf/build.xml:248: Compile failed; see the compiler error output for details.
Total time: 5 seconds
Re: [GUMP] Build Failure - jakarta-bsf
Posted by "Victor J. Orlikowski" <vi...@alumni.duke.edu>.
On Thu, Jul 03, 2003 at 05:46:30PM +0200, Igor Bukanov wrote:
> The method getWrappedException was always present in WrappedException,
> thus changing the code to use it instead of unwrap would be fully
> backfarwd and forward compatible while removing unnecessary cast. The
> unwrap would exist at least in the next public release.
>
Excellent! I must have missed that.
I'll make the change immediately.
Thanks!
Victor
--
Victor J. Orlikowski | The Wall is Down, But the Threat Remains!
=================================================================
orlikowski@apache.org | victor.j.orlikowski@alumni.duke.edu
Re: [GUMP] Build Failure - jakarta-bsf
Posted by Igor Bukanov <ig...@fastmail.fm>.
Victor J. Orlikowski wrote:
> On Thu, Jul 03, 2003 at 02:57:55PM +0200, Igor Bukanov wrote:
>
>>> [javac] /home/rubys/jakarta/jakarta-bsf/src/org/apache/bsf/engines/javascript/JavaScriptEngine.java:194: cannot resolve symbol
>>> [javac] symbol : method unwrap ()
>>> [javac] location: class org.mozilla.javascript.WrappedException
>>> [javac] t = (Throwable) ((WrappedException) t).unwrap();
>>> [javac] ^
>>> [javac] 1 error
>>>
>>>BUILD FAILED
>>>/home/rubys/jakarta/jakarta-bsf/build.xml:248: Compile failed; see the compiler error output for details.
>>
>>That code should be
>>t = ((WrappedException) t).getWrappedException();
>>and not
>>t = (Throwable) ((WrappedException) t).unwrap();
>>
>>But I will update Rhino with a deprecated version of the unwrap method
>>which was removed since WrappedException does not implement the Wrapper
>>interface any longer for implementation reasons.
>>
>
>
> Igor,
>
> Thanks for the clarification.
>
> How long do you expect that the deprecated API will be present? I
> ask because we would like to maintain compatibility with older
> versions of Rhino (at least 1.5 R3) without hacks (if possible).
The method getWrappedException was always present in WrappedException,
thus changing the code to use it instead of unwrap would be fully
backfarwd and forward compatible while removing unnecessary cast. The
unwrap would exist at least in the next public release.
Regards, Igor
Re: [GUMP] Build Failure - jakarta-bsf
Posted by "Victor J. Orlikowski" <vi...@alumni.duke.edu>.
On Thu, Jul 03, 2003 at 02:57:55PM +0200, Igor Bukanov wrote:
> > [javac] /home/rubys/jakarta/jakarta-bsf/src/org/apache/bsf/engines/javascript/JavaScriptEngine.java:194: cannot resolve symbol
> > [javac] symbol : method unwrap ()
> > [javac] location: class org.mozilla.javascript.WrappedException
> > [javac] t = (Throwable) ((WrappedException) t).unwrap();
> > [javac] ^
> > [javac] 1 error
> >
> > BUILD FAILED
> > /home/rubys/jakarta/jakarta-bsf/build.xml:248: Compile failed; see the compiler error output for details.
>
> That code should be
> t = ((WrappedException) t).getWrappedException();
> and not
> t = (Throwable) ((WrappedException) t).unwrap();
>
> But I will update Rhino with a deprecated version of the unwrap method
> which was removed since WrappedException does not implement the Wrapper
> interface any longer for implementation reasons.
>
Igor,
Thanks for the clarification.
How long do you expect that the deprecated API will be present? I
ask because we would like to maintain compatibility with older
versions of Rhino (at least 1.5 R3) without hacks (if possible).
If this is not a tenable position to maintain (from the
perspective of Rhino), then I'll commit the one-liner immediately.
Thanks,
Victor
--
Victor J. Orlikowski | The Wall is Down, But the Threat Remains!
=================================================================
orlikowski@apache.org | victor.j.orlikowski@alumni.duke.edu
Re: [GUMP] Build Failure - jakarta-bsf
Posted by Igor Bukanov <ig...@fastmail.fm>.
> [copy] Copying 1 file to /home/rubys/jakarta/jakarta-bsf/build/classes
> [javac] Compiling 51 source files to /home/rubys/jakarta/jakarta-bsf/build/classes
> [javac] /home/rubys/jakarta/jakarta-bsf/src/org/apache/bsf/engines/javascript/JavaScriptEngine.java:194: cannot resolve symbol
> [javac] symbol : method unwrap ()
> [javac] location: class org.mozilla.javascript.WrappedException
> [javac] t = (Throwable) ((WrappedException) t).unwrap();
> [javac] ^
> [javac] 1 error
>
> BUILD FAILED
> /home/rubys/jakarta/jakarta-bsf/build.xml:248: Compile failed; see the compiler error output for details.
That code should be
t = ((WrappedException) t).getWrappedException();
and not
t = (Throwable) ((WrappedException) t).unwrap();
But I will update Rhino with a deprecated version of the unwrap method
which was removed since WrappedException does not implement the Wrapper
interface any longer for implementation reasons.
Regards, Igor