On 30.04.2013 00:01, Gilles wrote:
If someone doesn't develop a Commons component, he is not in the
"developer"
category for that component.
If his app _uses_ a Commons component, he is a "user" of that component.
This kind of users should indeed be encouraged to test snapshots, and
report
proble
On 30 April 2013 00:20, Honton, Charles wrote:
> I am ambivalent. The change adds some, but not much extra clarity to the
> implementation. On the other hand, this change does change the public
> signatures of FormatCache. Is FormatCache considered part of the API?
>
>
No. It's package protect
I am ambivalent. The change adds some, but not much extra clarity to the
implementation. On the other hand, this change does change the public
signatures of FormatCache. Is FormatCache considered part of the API?
chas
On 4/29/13 2:06 AM, "sebb" wrote:
>https://issues.apache.org/jira/br
On Mon, 29 Apr 2013 22:47:15 +0100, sebb wrote:
On 29 April 2013 21:49, Gilles wrote:
On Mon, 29 Apr 2013 16:56:02 +0100, sebb wrote:
On 29 April 2013 15:51, Phil Steitz wrote:
On 4/29/13 5:39 AM, Jochen Wiedmann wrote:
> On Mon, Apr 29, 2013 at 11:02 AM, sebb wrote:
>
>> On 29 April 20
Sorry, hit wrong button - not yet used to the new GMail.
On 29 April 2013 19:36, Thomas Neidhart wrote:
> On 04/29/2013 11:02 AM, sebb wrote:
> > On 29 April 2013 09:42, Thomas Neidhart
> wrote:
> >
> >> Well, I certainly *want* to change the API if something is broken, so I
> >> guess an alpha
On 29 April 2013 19:36, Thomas Neidhart wrote:
> On 04/29/2013 11:02 AM, sebb wrote:
> > On 29 April 2013 09:42, Thomas Neidhart
> wrote:
> >
> >> Well, I certainly *want* to change the API if something is broken, so I
> >> guess an alpha release would be safer.
> >> I could imagine doing a firs
On 29 April 2013 21:49, Gilles wrote:
> On Mon, 29 Apr 2013 16:56:02 +0100, sebb wrote:
>
>> On 29 April 2013 15:51, Phil Steitz wrote:
>>
>> On 4/29/13 5:39 AM, Jochen Wiedmann wrote:
>>> > On Mon, Apr 29, 2013 at 11:02 AM, sebb wrote:
>>> >
>>> >> On 29 April 2013 09:42, Thomas Neidhart
>>>
On Mon, 29 Apr 2013 18:40:52 +0200, Luc Maisonobe wrote:
Hi all,
Since 2.x series, we have been struggling in several areas with
respect
to algorithms API. The latest change was about optimizer, but it is
only
one example among others (solvers, integration, ODE and maybe some
parts
of statis
On Mon, 29 Apr 2013 16:56:02 +0100, sebb wrote:
On 29 April 2013 15:51, Phil Steitz wrote:
On 4/29/13 5:39 AM, Jochen Wiedmann wrote:
> On Mon, Apr 29, 2013 at 11:02 AM, sebb wrote:
>
>> On 29 April 2013 09:42, Thomas Neidhart
wrote:
>>
>>> Well, I certainly *want* to change the API if som
On 04/29/2013 04:51 PM, Phil Steitz wrote:
> On 4/29/13 5:39 AM, Jochen Wiedmann wrote:
>> On Mon, Apr 29, 2013 at 11:02 AM, sebb wrote:
>>
>>> On 29 April 2013 09:42, Thomas Neidhart wrote:
>>>
Well, I certainly *want* to change the API if something is broken, so I
guess an alpha relea
On 04/29/2013 11:02 AM, sebb wrote:
> On 29 April 2013 09:42, Thomas Neidhart wrote:
>
>> Well, I certainly *want* to change the API if something is broken, so I
>> guess an alpha release would be safer.
>> I could imagine doing a first alpha till next week, and postpone some
>> changes to an alp
Hi all,
Since 2.x series, we have been struggling in several areas with respect
to algorithms API. The latest change was about optimizer, but it is only
one example among others (solvers, integration, ODE and maybe some parts
of statistics may be concerned by the proposal below).
The various thin
On 29 April 2013 15:51, Phil Steitz wrote:
> On 4/29/13 5:39 AM, Jochen Wiedmann wrote:
> > On Mon, Apr 29, 2013 at 11:02 AM, sebb wrote:
> >
> >> On 29 April 2013 09:42, Thomas Neidhart
> wrote:
> >>
> >>> Well, I certainly *want* to change the API if something is broken, so I
> >>> guess an a
On 4/29/13 5:39 AM, Jochen Wiedmann wrote:
> On Mon, Apr 29, 2013 at 11:02 AM, sebb wrote:
>
>> On 29 April 2013 09:42, Thomas Neidhart wrote:
>>
>>> Well, I certainly *want* to change the API if something is broken, so I
>>> guess an alpha release would be safer.
> Please keep upwards compatibil
On Mon, Apr 29, 2013 at 11:02 AM, sebb wrote:
> On 29 April 2013 09:42, Thomas Neidhart wrote:
>
> > Well, I certainly *want* to change the API if something is broken, so I
> > guess an alpha release would be safer.
>
Please keep upwards compatibility to any previous releases in mind.
Commons'
>Well, I certainly *want* to change the API if something is broken, so I
>guess an alpha release would be safer.
I could imagine doing a first alpha till next week, and postpone some
changes to an alpha2 release, as I will need a bit more time to work on the
Trie interface and maybe add a fluent AP
Hi Ron,
Thank you for the report. Can you create a JIRA for this please? Do
you have a fix perchance?
Gary
On Apr 29, 2013, at 1:53, Ron Wheeler wrote:
> http://commons.apache.org/proper/commons-codec/apidocs/org/apache/commons/codec/language/Metaphone.html
>
> "Note, that this does not match
https://issues.apache.org/jira/browse/LANG-884 has a patch to simplify
FastDateFormat which I would like to apply.
OK?
On 29 April 2013 09:42, Thomas Neidhart wrote:
> Well, I certainly *want* to change the API if something is broken, so I
> guess an alpha release would be safer.
> I could imagine doing a first alpha till next week, and postpone some
> changes to an alpha2 release, as I will need a bit more time
Well, I certainly *want* to change the API if something is broken, so I
guess an alpha release would be safer.
I could imagine doing a first alpha till next week, and postpone some
changes to an alpha2 release, as I will need a bit more time to work on the
Trie interface and maybe add a fluent API
On 29 April 2013 03:21, Gary Gregory wrote:
> Thoughts on generics for Codec
>
> I tried an approach to add generics to Codec here:
> https://svn.apache.org/repos/asf/commons/proper/codec/branches/generics
>
> I consider this (now old) experiment part success and part failure and I
> would like t
Le 29/04/2013 04:21, Gary Gregory a écrit :
> Upon reflection, it seems overly restrictive (thanks to Java) to have one
> encoding or decoding type per class. What should be the alternative for a
> nice OO design?
Just a wild guess, but would a builder pattern be suitable for codec?
Maybe someth
Gary Gregory wrote:
> Thoughts on generics for Codec
>
> I tried an approach to add generics to Codec here:
> https://svn.apache.org/repos/asf/commons/proper/codec/branches/generics
>
> I consider this (now old) experiment part success and part failure and I
> would like to share it here.
>
> I
23 matches
Mail list logo
