On 30 November 2011 22:15, henrib wrote:
> I've committed the fix on the 2.0 branch - tests are OK - and if 2.1 is ever
> released, this will be needed.
That's not quite the fix I had in mind, also I'm not sure it addresses
all the issues.
I'll apply my fix to the 2.0-API branch before too long
I've committed the fix on the 2.0 branch - tests are OK - and if 2.1 is ever
released, this will be needed.
--
View this message in context:
http://apache-commons.680414.n4.nabble.com/JEXL-binary-compatibility-tp4114818p4125259.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
On 30 November 2011 21:47, henrib wrote:
> If we go back to pre JEXL-83 fix (protected non final strict field + setter)
> and deprecate those, we can attempt releasing as 2.1 ?
I think that would get us almost there.
I propose to fix the strict/lenient bug in the 2.0-API-COMPAT branch
and do som
If we go back to pre JEXL-83 fix (protected non final strict field + setter)
and deprecate those, we can attempt releasing as 2.1 ?
--
View this message in context:
http://apache-commons.680414.n4.nabble.com/JEXL-binary-compatibility-tp4114818p4125129.html
Sent from the Commons - Dev mailing list
On 30 November 2011 17:11, henrib wrote:
>
> About Was: Dear #{p} Doe; Now: Dear ${p} Doe;
> As stated, the issue was that preparing a deferred expression must always
> return an immediate (even composite) expression. When preparing "Dear #{p}
> ${name};" , the immediate ${name} will be evaluated
About Was: Dear #{p} Doe; Now: Dear ${p} Doe;
As stated, the issue was that preparing a deferred expression must always
return an immediate (even composite) expression. When preparing "Dear #{p}
${name};" , the immediate ${name} will be evaluated - 'name' is the set of
variables - and the prepara
On 30 November 2011 15:34, henrib wrote:
> About Test org.apache.commons.jexl2.UnifiedJEXLTest that failed, the code had
> bugs and was fixed.
> 1187458 Fri Oct 21 18:40:17 CEST 2011 henrib
> Added getVariables method (similar to JexlEngine) to extract all references
> variables from an UJEXL ex
About Test org.apache.commons.jexl2.UnifiedJEXLTest that failed, the code had
bugs and was fixed.
1187458 Fri Oct 21 18:40:17 CEST 2011 henrib
Added getVariables method (similar to JexlEngine) to extract all references
variables from an UJEXL expression;
Fixed issue where preparing a deferred ex
On 29 November 2011 16:30, sebb wrote:
> On 28 November 2011 16:26, sebb wrote:
>> On 28 November 2011 15:55, henrib wrote:
>>> I added @since 2.1, renamed the Uberspect.getConstructor, removed final for
>>> silent & strict in Interpreter (although Interpreter instances probably
>>> never need t
On 28 November 2011 16:26, sebb wrote:
> On 28 November 2011 15:55, henrib wrote:
>> I added @since 2.1, renamed the Uberspect.getConstructor, removed final for
>> silent & strict in Interpreter (although Interpreter instances probably
>> never need to change those at runtime) but there are still
On 28 November 2011 15:55, henrib wrote:
> I added @since 2.1, renamed the Uberspect.getConstructor, removed final for
> silent & strict in Interpreter (although Interpreter instances probably
> never need to change those at runtime) but there are still 21 clirr errors
> that I'm afraid many will
I added @since 2.1, renamed the Uberspect.getConstructor, removed final for
silent & strict in Interpreter (although Interpreter instances probably
never need to change those at runtime) but there are still 21 clirr errors
that I'm afraid many will consider as show-stoppers for release.
I'm pretty
On 28 November 2011 14:35, henrib wrote:
> @since, will do.
>
> On the Script interface, I suspect anyone implementing it derives
> ExpressionImpl which does carry default implementations...
That then might be an acceptable break in compatibility.
> On the new Script methods (getVariables etc),
@since, will do.
On the Script interface, I suspect anyone implementing it derives
ExpressionImpl which does carry default implementations...
On the new Script methods (getVariables etc), I'd like to keep the API
simple and avoid multiplying interfaces (esp for 2/3 methods at a time).
Thanks for
14 matches
Mail list logo
