On 28 November 2011 14:30, sebb wrote:
> On 28 November 2011 14:19, henrib wrote:
>> Thanks for tidying up my mess.
>>
>> About org.apache.commons.jexl2.UnifiedJEXL$Expression, its subclasses are
>> private because only that base class is supposed to be usable by end-users;
>> one declares 'Unifi
On 28 November 2011 13:51, henrib wrote:
> One might argue that JEXL does not have that many users so jar hell is very
> (very) unlikely - no Apache project depends on jexl2 afaik - and that
> forcing "up to date/snapshot" users to switch to a new package when they're
> already used to recompile a
On 28 November 2011 14:19, henrib wrote:
> Thanks for tidying up my mess.
>
> About org.apache.commons.jexl2.UnifiedJEXL$Expression, its subclasses are
> private because only that base class is supposed to be usable by end-users;
> one declares 'UnifiedJEXL.Expression expr' and the engine manages
Thanks for tidying up my mess.
About org.apache.commons.jexl2.UnifiedJEXL$Expression, its subclasses are
private because only that base class is supposed to be usable by end-users;
one declares 'UnifiedJEXL.Expression expr' and the engine manages the rest.
org.apache.commons.jexl2.internal is def
One might argue that JEXL does not have that many users so jar hell is very
(very) unlikely - no Apache project depends on jexl2 afaik - and that
forcing "up to date/snapshot" users to switch to a new package when they're
already used to recompile against the latest JEXL version is adding burden
on
On 28 November 2011 12:03, James Carman wrote:
> I don't think that is either an apache thing or a rule. It's more of a
> commons best practice. It's one we strongly suggest for good reason,
> though.
Yes, because commons components are generally low-level libraries
which can be part of a depen
I don't think that is either an apache thing or a rule. It's more of a
commons best practice. It's one we strongly suggest for good reason,
though. Make sure the maven artifactId (and probably groupId too) changes
correspondingly. This will allow older versions to coexist with new ones.
On Nov
On 28 November 2011 09:40, sebb wrote:
> On 28 November 2011 01:40, sebb wrote:
>> On 28 November 2011 01:03, Gary Gregory wrote:
>>> I see 35 Clirr Errors that point to backwards incompatibility.
>>
>> Many of these relate to the parser, which is not really part of the public
>> API.
>
> Just
On 28 November 2011 01:40, sebb wrote:
> On 28 November 2011 01:03, Gary Gregory wrote:
>> I see 35 Clirr Errors that point to backwards incompatibility.
>
> Many of these relate to the parser, which is not really part of the public
> API.
Just checked, and the clirr plugin supports an excludes
Cancelled vote.
Henrib
--
View this message in context:
http://apache-commons.680414.n4.nabble.com/VOTE-Release-JEXL-2-1-based-on-RC1-tp4113403p4114453.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
-
To un
Gary and Sebb pointed out that, per apache release rules, incompatible binaries
require new package name (i.e. jexl3).
My bad, sorry.
Henrib
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e
On 28 November 2011 01:03, Gary Gregory wrote:
> I see 35 Clirr Errors that point to backwards incompatibility.
Many of these relate to the parser, which is not really part of the public API.
However, there are some which do look like they break binary compatibility
> So... do we have a Commons
I see 35 Clirr Errors that point to backwards incompatibility.
So... do we have a Commons-wide policy of changing package names and making
a major release (3.0 vs. 2.1 here) or not?
Gary
On Sun, Nov 27, 2011 at 1:34 PM, Henri Biestro wrote:
>
> Dear all,
>
> After a pretty long cycle, JEXL 2.1
Dear all,
After a pretty long cycle, JEXL 2.1 is ready for review.
Here is a quick list of new features (from the release notes):
What's new in 2.1:
==
* A more thorough arithmetic (JexlArithmetic) that allows fine control over
decimals (scale and precision), a
new syntax for
14 matches
Mail list logo
