commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: Release JEXL 3.0 based on RC1
Date Tue, 29 Nov 2011 17:18:38 GMT
On 29 November 2011 17:00, Henri Biestro <> wrote:
> Dear all,
> JEXL 3.0 is ready for review.
> The 2.1 attempt comments have been folded in; JEXL 3 being binary and source code incompatible
with JEXL 2, the code has moved to the new o.a.c.jexl3 package.
> I've also moved some classes to the internal packages to make the public API clearer
for the future.
> Here is a quick list of new features (from the release notes):
> What's new in 3.0:
> ==================
> * A more thorough arithmetic (JexlArithmetic) that allows fine control over decimals
(scale and precision), a
>  new syntax for numeric literals (OGNL inspired Big and Huge notations) and a better
type handling keeping the most
>  appropriate representation in casual operations.
> * The introduction of script variables and parameters that reduce context dependencies
and methods; this allows to
>  perform checks after script creation (light static checking hints). Plus the ability
to call script from scripts.
> * A sandoxing feature to restrict and rename what JEXL can access from the environment
allowing tighter control over security.
> * Extensions to UnifiedJEXL that allow the creation of templates.
> New features in 3.0:
> ====================
> * JEXL-114:     Allow scripts to create local variables // Add return keyword
> * JEXL-113:     Add functions to extract which variables, parameters and local variables
are used to evaluate a script
> * JEXL-118:     Provide an IN operator
> * JEXL-115:     Add support for asynchronous script execution and cancellation
> * JEXL-116:     Add control over classes, methods, constructors and properties allowed
in scripts
> * JEXL-120:     Add simple template features
> * JEXL-119:     Allow indexed properties container resolution in expressions
> Tested against Java 1.{5,6} / Maven{2,3}, Windows 7/Linux/Mac OS.
> Tag:
> Site:
> Binaries:
> This vote will close in 72 hours, 08:00PM GMT, Dec 3rd.
>  [ ] +1 Release these artifacts
>  [ ] +0 OK, but...
>  [ ] -0 OK, but really should fix...
>  [X] -1 I oppose this release because...

The <artifactId> has not been changed; this will caused lots of
problems if released to Maven Central.

However, that is not the only reservation I have.

Are we sure that all API-breaking changes have been fixed in this release?

Until I have had time for further investigation, I must vote -1 even
if the artifactId issue is fixed.

This is not to say I think it's wrong to change the package name (and
artifactId) and release version.
But such a major change needs careful scrutiny to make sure all the
required changes are done at the same time.
Otherwise, there will likely need to be a further major release/rename.

I am also a bit disappointed that we don't seem to have fully explored
fixing the API breakages.
It may turn out to be necessary to go through the rename, but it would
be easier for all users if the release were a drop-in replacement.

> Many thanks,
> Regards.
> Henrib

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message