Old code was executing self.setValue() and the current behaviour breaks
backward compatibility. I have tried old ScriptCondition.eval() and it fixed
the problem. I think we should add "expression" attribute to
AbstractScriptComponent and change it to use it with evaluateScript(),
otherwise nested text will be executed with old executeScript() call.
- Alexey.
On 7/31/07, Peter Reilly <[EMAIL PROTECTED]> wrote:
>
> For BSF there are two methods to run a script:
> eval and exec,
>
> In ant 1.6.* the only method supported was exec. Hence all
> the <script*> types called methods on self to set the return
> value.
>
> For ant 1.7.0, I modified the scripting code to allow access to
> eval and exec, but did not modify any calling types to use
> eval rather than exec. (In fact I did not test the eval on anything)
> I placed it here to allow expression handling from property callbacks
> - something like <if test='${groovy: abc == "abc"}"> ..., but did
> not follow up.
>
> I assume that jython does not like a new line in its expression.
>
> one can in python do
> a = 1
> if a > 0:
> b = 2
> however, one cannot do
> if #
> a > 0:
>
>
> ...
> So I think that this is a clear case of BC problem.
> It would be nearly impossible to use <scriptcondition> with
> jythton in it's current state.
>
>
> (I cannot test at the moment due to (bsf/log4j/commons
> logging/jython.jar issues)
>
> Peter
>
>
>
> On 7/31/07, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> > On 7/31/07, Matt Benson <[EMAIL PROTECTED]> wrote:
> > > <scriptcondition> originally behaved such that a
> > > default value can be declared on the task as an
> > > attribute, and the embedded script can set the
> > > condition value. I preserved this behavior, but added
> > > a preference for a return value, if any, from the
> > > script: again, on the basis that this seemed a (more)
> > > natural behavior to me. DD, you said "not returning a
> > > value is fine by you"... and that's what
> > > <scriptcondition> always did, and _should_ still
> > > allow... am _I_ missing anything (other than whatever
> > > I've apparently done to break python compatibility)?
> >
> > Ah, sorry, I meant that "not returning a value is meaningless to me".
> > Sure, if a default value for the condition is set as an attribute, why
> > not (although I don't see why that's necessary or useful), but a
> > scriptcondition is supposed to be a script fragment which returns a
> > boolean value, and I don't see the point of not returning a value.
> > --DD
> >
> > PS: The error message could be nicer though ;-)
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Alexey N. Solofnenko
Home: http://trelony.cjb.net/
Pleasant Hill, CA (GMT-8 usually)
