ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@yahoo.com>
Subject Re: <scriptcondition> is broken with Jython in the recent trunk builds
Date Fri, 10 Aug 2007 17:52:35 GMT

--- Alexey Solofnenko <A.Solofnenko@mdl.com> wrote:

> 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.

I guess at this point I'd just roll it back until we
can come up with a solution that pleases everyone.

-Matt

> 
> - 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)
> 



       
____________________________________________________________________________________
Sick sense of humor? Visit Yahoo! TV's 
Comedy with an Edge to see what's on, when. 
http://tv.yahoo.com/collections/222

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


Mime
View raw message