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 Wed, 01 Aug 2007 00:08:42 GMT

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


Mime
View raw message