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 Nabbl
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
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
ionException with the same message
(or log an error if silent?) and document the change explicitly in the
release notes.
--
View this message in context:
http://apache-commons.680414.n4.nabble.com/JEXL-binary-compatibility-tp4114818p4123859.html
Sent fro
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
through the engine.
--
View this message in context:
http://apache-commons.680414.n4.nabble.com/JEXL-binary-compatibility-tp4114818p4123418.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
-
To unsubscribe, e
t; If it does prove necessary, then we should check that there aren't any
> other issues with the API that still need fixing.
>
> Otherwise the process will repeat ...
>
>>> Cheers,
>>> Henrib
>>>
>>>
>>>
>>>
>>> --
in case jexl2 is a
>> dead-end.
If it does prove necessary, then we should check that there aren't any
other issues with the API that still need fixing.
Otherwise the process will repeat ...
>> Cheers,
>> Henrib
>>
>>
>>
>>
Script interface, which
may be allowed.
> I've got a migrated-to jexl3 code base ready just in case jexl2 is a
> dead-end.
>
> Cheers,
> Henrib
>
>
>
>
> --
> View this message in context:
> http://apache-commons.680414.n4.nabble.com/JEXL-binary-compati
ead-end.
Cheers,
Henrib
--
View this message in context:
http://apache-commons.680414.n4.nabble.com/JEXL-binary-compatibility-tp4114818p4115683.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
-
To
ntext:
> http://apache-commons.680414.n4.nabble.com/JEXL-binary-compatibility-tp4114818p4115380.html
> Sent from the Commons - Dev mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@c
s for the review
Henrib
--
View this message in context:
http://apache-commons.680414.n4.nabble.com/JEXL-binary-compatibility-tp4114818p4115380.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
-
To unsubscri
The interface org.apache.commons.jexl2.Script has been extended with
several methods.
There's no default abstract implementation so I assume this will cause
problems for client code.
Would it be make sense to implement the new methods in a
sub-interface? Or an independent interface?
In particular,
15 matches
Mail list logo
