On 3 December 2011 00:08, sebb seb...@gmail.com wrote:
To run the 2.0.1 tests against 2.1-SNAPSHOT, I have set up the branch
https://svn.apache.org/repos/asf/commons/proper/jexl/branches/COMMONS_JEXL_2_0_1_TEST
This is a copy ot the 2.0.1 tag, with minimal changes to the tests to
handle new
Hi Stefan,
thank you for your insights.
Am 03.12.2011 08:25, schrieb Stefan Bodewig:
Hi Oliver,
On 2011-12-02,ohe...@apache.org wrote:
Another attempt to fix the GUMP build using an ugly cast.
Seeing you jumping through these hoops I wonder whether it wouldn't be
better to look at the
On 3 December 2011 07:25, Stefan Bodewig bode...@apache.org wrote:
Hi Oliver,
On 2011-12-02, ohe...@apache.org wrote:
Another attempt to fix the GUMP build using an ugly cast.
- MapObject, Object systemProperties = System.getProperties();
+ // This is ugly, but it is safe
When building I get a heap space error in
testSpeedCheck(org.apache.commons.codec.language.bm.BeiderMorseEncoderTest),
even when setting MAVEN_OPTS=-Xmx1024m. I remember there was discussion
about this for the last RC. Which amount of memory is required?
Otherwise, I did not find major
The Jexl 2.0 branch now has only a few binary incompatibilities
reported by Clirr.
According to the JLS [1], adding methods to an interface does not
break *binary* compatibility; however of course it will break source
compatibility.
Either Clirr is not distinguishing the binary/source cases, or
On 3 December 2011 03:06, Gary Gregory ggreg...@apache.org wrote:
Good day to you all:
I have prepared Commons Codec 1.6-RC2, again, per Sebb's suggestion. I am
not calling it RC3 because there are no changes in source files from the
last RC. The only difference is that I built from a fresh
If the last hurdle to binary compatibility is replacing DebugInfo by
JexlInfo, by all means, replace it!
Nice analysis and great result.
Thanks for your efforts,
Cheers
Henrib
Ps any comment on the difference between stability and usability and
possible solutions, cd release process post?
--
On 2011-12-03, Oliver Heger wrote:
Is configuration's dependency on Digester new or why have we started to
see this error just now? You may want to upgrade to Digester 2.0 or 2.1
to start with (or even Digester3?) if it is new. If it isn't then
obviously 2.x isn't compatible enough to 1.x
On Sat, Dec 3, 2011 at 5:45 AM, Oliver Heger
oliver.he...@oliver-heger.dewrote:
When building I get a heap space error in testSpeedCheck(org.apache.**
commons.codec.language.bm.**BeiderMorseEncoderTest), even when setting
MAVEN_OPTS=-Xmx1024m. I remember there was discussion about this for the
On Sat, Dec 3, 2011 at 7:12 AM, sebb seb...@gmail.com wrote:
On 3 December 2011 03:06, Gary Gregory ggreg...@apache.org wrote:
Good day to you all:
I have prepared Commons Codec 1.6-RC2, again, per Sebb's suggestion. I am
not calling it RC3 because there are no changes in source files
On Sat, Dec 3, 2011 at 5:45 AM, Oliver Heger
oliver.he...@oliver-heger.dewrote:
When building I get a heap space error in testSpeedCheck(org.apache.**
commons.codec.language.bm.**BeiderMorseEncoderTest), even when setting
MAVEN_OPTS=-Xmx1024m. I remember there was discussion about this for the
I took a look at the Continuum build error from Nov 26th and the error is
that adding getSQLXML() in BeanProcessor.java requires
importing java.sql.SQLXML which was introduced in Java 1.6.
Currently DBUTILS is set to only require Java 1.5.
Thoughts?
Bill-
On Sat, Nov 26, 2011 at 4:09 PM,
On Sat, Dec 3, 2011 at 12:04 PM, William Speirs wspe...@apache.org wrote:
I took a look at the Continuum build error from Nov 26th and the error is
that adding getSQLXML() in BeanProcessor.java requires
importing java.sql.SQLXML which was introduced in Java 1.6.
Currently DBUTILS is set to
Am 03.12.2011 17:18, schrieb Gary Gregory:
On Sat, Dec 3, 2011 at 5:45 AM, Oliver Heger
oliver.he...@oliver-heger.dewrote:
When building I get a heap space error in testSpeedCheck(org.apache.**
commons.codec.language.bm.**BeiderMorseEncoderTest), even when setting
MAVEN_OPTS=-Xmx1024m. I
Since it may need clarification;
The idea would be to allow a clirr report to give accurate analysis of
whether the external / stable API has been modified.
Methods or classes annotated as @stable, could not change from one version
to another before they are @deprecated.
Methods or classes
On Sat, Dec 3, 2011 at 3:14 PM, Oliver Heger
oliver.he...@oliver-heger.dewrote:
Am 03.12.2011 17:18, schrieb Gary Gregory:
On Sat, Dec 3, 2011 at 5:45 AM, Oliver Heger
oliver.he...@oliver-heger.de**wrote:
When building I get a heap space error in testSpeedCheck(org.apache.**
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=15343projectId=75
Build statistics:
State: Failed
Previous State: Ok
Started at: Sat 3 Dec 2011 21:37:19 +
Finished at: Sat 3 Dec 2011 21:37:52 +
Total time: 33s
Build Trigger: Schedule
Build
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=15346projectId=75
Build statistics:
State: Failed
Previous State: Failed
Started at: Sat 3 Dec 2011 22:40:44 +
Finished at: Sat 3 Dec 2011 22:41:19 +
Total time: 35s
Build Trigger: Schedule
Build
On 12/2/11 3:45 PM, henrib wrote:
It seems to me we have a hard time allowing both stability and usability.
Stability of APIs does not contradict usability of the library, at least
should not.
Some of us are looking for very long term/stable/high-quality solutions
because they need to
I applaud the initiative and creative suggestion above. I wonder,
though, what users would make of it. My first thought as a user
would be to avoid ever using the unstable stuff but I can imagine
scenarios where I might.
Hi,
I was wondering the same thing, from a user perspective too. I
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-exec-test has an issue affecting its community integration.
This
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-digester3-test has an issue affecting its community integration.
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-proxy-test has an issue affecting its community integration.
This
On 2011-12-03, William Speirs wrote:
I also added my fingerprint to LDAP and I've created a RDF file as
well, but again I don't yet see my info here:
http://people.apache.org/committers.html Again, I'm guessing/hoping
that it just takes a while to perform the sync.
There are a bunch of shell
On 2011-12-02, henrib wrote:
It seems to me we have a hard time allowing both stability and usability.
Stability of APIs does not contradict usability of the library, at least
should not.
I'm glad you say that right at the beginning as the versus in the
subject line seems to imply something
Phil Steitz wrote
In practical terms, it might be hard to decide what to put where.
Can you provide some examples based on recent RCs?
When trying to release JEXL 2.1, the API was disrupted and the clirr report
was outputing lots of clutter.
As the dev, it became very hard to understand
26 matches
Mail list logo
