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
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 somethi
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 sh
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
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.
T
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 i
>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.
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 a
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=15346&projectId=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
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=15343&projectId=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 Num
On Sat, Dec 3, 2011 at 3:14 PM, Oliver Heger
wrote:
> Am 03.12.2011 17:18, schrieb Gary Gregory:
>
>> On Sat, Dec 3, 2011 at 5:45 AM, Oliver Heger
>> **wrote:
>>
>> When building I get a heap space error in testSpeedCheck(org.apache.**
>>> commons.codec.language.bm.BeiderMorseEncoderTest), ev
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 annotat
Am 03.12.2011 17:18, schrieb Gary Gregory:
On Sat, Dec 3, 2011 at 5:45 AM, Oliver Heger
wrote:
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 abou
On Sat, Dec 3, 2011 at 12:04 PM, William Speirs 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 only require Ja
>
> OK... I think I've created a GPG code signing key and updated all the
> proper documents. I'm a bit worried I did something wrong because my key
> does show up here: http://www.apache.org/dist/commons/KEYS but I'm
> guessing/hoping it just takes time to sync things up. I updated that file
> on
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, Simone
On Sat, Dec 3, 2011 at 5:45 AM, Oliver Heger
wrote:
> 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 o
On Sat, Dec 3, 2011 at 7:12 AM, sebb wrote:
> On 3 December 2011 03:06, Gary Gregory 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 onl
On Sat, Dec 3, 2011 at 5:45 AM, Oliver Heger
wrote:
> 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 o
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 t
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?
--
View
On 3 December 2011 03:06, Gary Gregory 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 checkout of the
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 it
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 problem
On 3 December 2011 07:25, Stefan Bodewig wrote:
> Hi Oliver,
>
> On 2011-12-02, wrote:
>
>> Another attempt to fix the GUMP build using an ugly cast.
>> - Map systemProperties = System.getProperties();
>> + // This is ugly, but it is safe because the Properties object
>> returned
Hi Stefan,
thank you for your insights.
Am 03.12.2011 08:25, schrieb Stefan Bodewig:
Hi Oliver,
On 2011-12-02, 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 core issue. If conf
On 3 December 2011 00:08, sebb 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 features in t
27 matches
Mail list logo
