ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexey Solofnenko <A.Solofne...@mdl.com>
Subject Re: <scriptcondition> is broken with Jython in the recent trunk builds
Date Fri, 10 Aug 2007 16:52:10 GMT
I think we need to restore old functionality, because it was done after 
1.7 was released. Or it can be made smarter by checking if setValue() 
was called and use that value instead of return value. Again we need to 
decide if we want 100% backward compatibility or slightly less.

- Alexey.

Matt Benson wrote:
> --- Alexey Solofnenko <trelony@gmail.com> wrote:
>
>   
>> Sorry about that. Personally I would prefer
>> "expression" attribute to
>> contain an expression itself - it is supposed to be
>> simple.
>>
>>     
>
> That still doesn't address the situation I mentioned,
> whereby some arbitrary scripty stuff is done to
> calculate a final result, then return it.  It seems
> that experience has shown we shouldn't discriminate
> between an attribute and nested text.  Maybe a
> different attribute name would better express the
> concept I am after.
>
> -Matt
>
>   
>> - Alexey.
>>
>> On 7/31/07, Matt Benson <gudnabrsam@yahoo.com>
>> wrote:
>>     
>>> --- Alexey Solofnenko <trelony@gmail.com> wrote:
>>>
>>>       
>>>> It is just a thought - should ScriptFilter,
>>>> ScriptMapper, ... also return a
>>>> value instead of setting it?
>>>>
>>>>         
>>> mmmm.... I don't know!  :)  In hindsight maybe it
>>> would have been better to leave this can of worms
>>> unmolested rather than deal with these concepts of
>>> consistency...  I suppose that in either of those
>>> cases it might well be reasonable to handle a
>>>       
>> return
>>     
>>> value.  But with good old Python, what--you can't
>>> execute arbitrary junk, return a value, and
>>>       
>> consider
>>     
>>> that an evaluation?  Jython seems to be a pain
>>> overall... seems like every time I have to deal
>>>       
>> with
>>     
>>> it there's a headache involved.  If we do extend
>>>       
>> this
>>     
>>> concept, I suppose we could pull up "expression"
>>>       
>> to
>>     
>>> AbstractScriptComponent, and have evaluate()
>>>       
>> delegate
>>     
>>> to execute() and return null when expression ==
>>> false... then any type that wanted to support a
>>>       
>> return
>>     
>>> value could just switch to calling evaluate and
>>>       
>> prefer
>>     
>>> a return value to whatever its "legacy" mechanisms
>>> were.  How does this sound?
>>>
>>> -Matt
>>>
>>>       
>>>> - Alexey.
>>>>
>>>> On 7/31/07, Matt Benson <gudnabrsam@yahoo.com>
>>>> wrote:
>>>>         
>>>>> --- Alexey Solofnenko <trelony@gmail.com>
>>>>>           
>> wrote:
>>     
>>>>>> 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.
>>>>>>             
>>>>> Thanks for running this down, Alexey.  I see
>>>>>           
>> where
>>     
>>>>> you're coming from with the "expression"
>>>>>           
>>>> attribute,
>>>>         
>>>>> though I'm not sure I agree it should live all
>>>>>           
>> the
>>     
>>>> way
>>>>         
>>>>> up in AbstractScriptComponent, because we
>>>>>           
>> can't
>>     
>>>> use it
>>>>         
>>>>> to automatically drive anything.  I am going
>>>>>           
>> to
>>     
>>>> add it
>>>>         
>>>>> to ScriptCondition directly; if we change our
>>>>>           
>>>> minds
>>>>         
>>>>> later pulling it up shouldn't cause any
>>>>>           
>> problems.
>>     
>>>>> -Matt
>>>>>
>>>>>           
>>>>>> - Alexey.
>>>>>>
>>>>>> On 7/31/07, Peter Reilly
>>>>>> <peter.kitt.reilly@gmail.com> 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
>>>>>>>               
>>>>>> <ddevienne@gmail.com> wrote:
>>>>>>             
>>>>>>>> On 7/31/07, Matt Benson
>>>>>>>>                 
>>>> <gudnabrsam@yahoo.com>
>>>>         
>>>>>> 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:
>>>>>>>>                 
>>>>>> 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
>>>>>>             
>>>>>>>               
>>>>>> --
>>>>>> Alexey N. Solofnenko
>>>>>> Home: http://trelony.cjb.net/
>>>>>> Pleasant Hill, CA (GMT-8 usually)
>>>>>>
>>>>>>             
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>           
>>>       
> ____________________________________________________________________________________
>   
>>>>> Choose the right car based on your needs. 
>>>>>           
>> Check
>>     
>>>> out Yahoo! Autos new Car
>>>>         
>>>>> Finder tool.
>>>>> http://autos.yahoo.com/carfinder/
>>>>>
>>>>>
>>>>>           
> ---------------------------------------------------------------------
>   
>>>>> To unsubscribe, e-mail:
>>>>>           
>>>> dev-unsubscribe@ant.apache.org
>>>>         
>>>>> For additional commands, e-mail:
>>>>>           
>>>> dev-help@ant.apache.org
>>>>         
>>>>>           
>>>> --
>>>> Alexey N. Solofnenko
>>>> Home: http://trelony.cjb.net/
>>>> Pleasant Hill, CA (GMT-8 usually)
>>>>
>>>>         
>>>
>>>
>>>
>>>
>>>       
> ____________________________________________________________________________________
>   
>>> Pinpoint customers who are looking for what you
>>>       
>> sell.
>>     
>>> http://searchmarketing.yahoo.com/
>>>
>>>
>>>       
> ---------------------------------------------------------------------
>   
>>> To unsubscribe, e-mail:
>>>       
>> dev-unsubscribe@ant.apache.org
>>     
>>> For additional commands, e-mail:
>>>       
>> dev-help@ant.apache.org
>>     
>>>       
>> -- 
>> Alexey N. Solofnenko
>> Home: http://trelony.cjb.net/
>> Pleasant Hill, CA (GMT-8 usually)
>>
>>     
>
>
>
>        
> ____________________________________________________________________________________
> Choose the right car based on your needs.  Check out Yahoo! Autos new Car Finder tool.
> http://autos.yahoo.com/carfinder/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>   

-- 
------------------------------------------------------------------------
Alexey N. Solofnenko <http://trelony.cjb.net/>
Pleasant Hill, CA (GMT-8 usually)

Mime
View raw message