You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Henrib <hb...@gmail.com> on 2009/07/17 17:50:22 UTC
[JEXL] towards 2.0 release, bug triage
Out of the 20 unresolved issues in Jira, the following list is addressed in
the 2.0 trunk:
JEXL-52 Implicit evaluation of misspelled EL and ways to detect such
occurrences
JEXL-48 NPE during expression evaluation
JEXL-44 Comments don't allow double-quotes
JEXL-41 Allow nested ${} evaluation
JEXL-47 Allow single-line comments with //
JEXL-42 NullPointerException evaluating an expression
JEXL-10 [jexl] Make possible checking for unresolved variables
JEXL-11 [jexl] Don't make null convertible into anything
JEXL-3 [JEXL] Static method resolution (and changes to context)
JEXL-21 operator overloading / hooks on operator processing
JEXL-49 Block statements aren't parsed
JEXL-45 Unhandled division by zero
JEXL-50 Div operator does not do integer division
JEXL-32 BigDecimal values are treated as Long values which results in loss
of precision
JEXL-24 Support Long for integer literal instead of Integers
JEXL-58 UnifiedJEXL
Most of them have been opened for a long time and I suppose no-one will be
willing to fix anything in the 1.1 trunk. May I suggest that the target
release for all bugs becomes 2.0 to begin with since I suspect that their
reporters have either found workarounds and/or are no longer expecting a
fix.
In that same list, besides JEXL-52 that represents a lot of work and might
be tagged as later, all others can be marked as fixed in 2.0 (as far as I
understand them).
Non-yet adressed issues are:
JEXL-46 adding Perl-like regular-expression operators
JEXL-43 Website overview does not mention method calls
JEXL-35 Final API requirements
JEXL-20 Fix checkstyle issues in 1.1 (should be(come) 2.0)
As a personal opinion:
JEXL-46 should not be fixed or marked as later since adding syntactic
elements (especially regexps) is a step towards more complexity.
JEXL-43 - or more globally the new 2.0 features & al - should definitely be
part of the web-site somehow and thus be fxied.
JEXL-35 remaining question should be whether JexlArithmetic should become
public so it makes it easier to implement another Arithmetic.
JEXL-20 (besides being retargeted to 2.0) is difficult to assess to me; what
is the tolerable/authorized/common overall-quality we are seeking in this
respect?
Opinions, comments welcome.
--
View this message in context: http://www.nabble.com/-JEXL--towards-2.0-release%2C-bug-triage-tp24537050p24537050.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [JEXL] towards 2.0 release, bug triage
Posted by Rahul Akolkar <ra...@gmail.com>.
On Fri, Jul 17, 2009 at 11:50 AM, Henrib<hb...@gmail.com> wrote:
>
> Out of the 20 unresolved issues in Jira, the following list is addressed in
> the 2.0 trunk:
>
> JEXL-52 Implicit evaluation of misspelled EL and ways to detect such
> occurrences
> JEXL-48 NPE during expression evaluation
> JEXL-44 Comments don't allow double-quotes
> JEXL-41 Allow nested ${} evaluation
> JEXL-47 Allow single-line comments with //
> JEXL-42 NullPointerException evaluating an expression
> JEXL-10 [jexl] Make possible checking for unresolved variables
> JEXL-11 [jexl] Don't make null convertible into anything
> JEXL-3 [JEXL] Static method resolution (and changes to context)
> JEXL-21 operator overloading / hooks on operator processing
> JEXL-49 Block statements aren't parsed
> JEXL-45 Unhandled division by zero
> JEXL-50 Div operator does not do integer division
> JEXL-32 BigDecimal values are treated as Long values which results in loss
> of precision
> JEXL-24 Support Long for integer literal instead of Integers
> JEXL-58 UnifiedJEXL
>
> Most of them have been opened for a long time and I suppose no-one will be
> willing to fix anything in the 1.1 trunk. May I suggest that the target
> release for all bugs becomes 2.0 to begin with since I suspect that their
> reporters have either found workarounds and/or are no longer expecting a
> fix.
>
<snip/>
Indeed, I thought about doing this last night, but decided to get some
sleep instead :-) Here is the cleaned up JIRA roadmap, which agrees
with above:
https://issues.apache.org/jira/browse/JEXL?report=com.atlassian.jira.plugin.system.project:roadmap-panel
> In that same list, besides JEXL-52 that represents a lot of work and might
> be tagged as later, all others can be marked as fixed in 2.0 (as far as I
> understand them).
<snap/>
I've created a new version called "Later" for good ideas that won't
get on the immediate roadmap without complete tested patches. JEXL-52
is one example.
>
> Non-yet adressed issues are:
> JEXL-46 adding Perl-like regular-expression operators
> JEXL-43 Website overview does not mention method calls
> JEXL-35 Final API requirements
> JEXL-20 Fix checkstyle issues in 1.1 (should be(come) 2.0)
>
> As a personal opinion:
> JEXL-46 should not be fixed or marked as later since adding syntactic
> elements (especially regexps) is a step towards more complexity.
<snap/>
Another "Later" IMO.
> JEXL-43 - or more globally the new 2.0 features & al - should definitely be
> part of the web-site somehow and thus be fxied.
<snip/>
Definitely 2.0.
> JEXL-35 remaining question should be whether JexlArithmetic should become
> public so it makes it easier to implement another Arithmetic.
<snap/>
I think theres value to that, which means we need to be very sure
thats the interface we want (or even go to an abstract class for
extensibility I think). Set to 2.0.
> JEXL-20 (besides being retargeted to 2.0) is difficult to assess to me; what
> is the tolerable/authorized/common overall-quality we are seeking in this
> respect?
>
<snip/>
Well, very subjective IMO. Generally try to fix as many as possible
and make code consistent in most syntactic and style respects.
Thanks for the triage.
-Rahul
> Opinions, comments welcome.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org