On 7/9/12 2:08 PM, Matt Benson wrote:
> I am still thinking this through... Commons policy permits any Apache
> committer to start a sandbox component, but IMO it is tacitly implied
> that the associated code come directly from the committer/s, or from
> another Apache project. This implies that t
Dear Jared,
Yes, that would be very nice to have such an addition! Remember to
also include unit tests (refer to the current ones for examples). The
best would be to split a submission up into multiple minor ones, each
covering a natural submission (e.g. multivariate Normal distribution
in one sub
I am still thinking this through... Commons policy permits any Apache
committer to start a sandbox component, but IMO it is tacitly implied
that the associated code come directly from the committer/s, or from
another Apache project. This implies that this development would
either:
- take place in
Hello,
I have implemented some classes for multivariate Normal distributions,
multivariate normal mixture models, and an expectation maximization fitting
class for the mixture model. I would like to submit it to Apache Commons Math.
I still have some touching up to do so that they fit the sty
Matt is correct. I will ping my coworkers and see who would be available to
help out and we will go from there.
Thanks,
Scott ES
On Jul 9, 2012, at 2:19 PM, Matt Benson wrote:
> If Scott were an Apache committer (he is not), that would be true. ;)
> Instead, the situation is more complicated
If Scott were an Apache committer (he is not), that would be true. ;)
Instead, the situation is more complicated. Is this component part
of the current Camel codebase? If so (or even if not?), perhaps one
or more of the Camel committers would care to manage the code in the
Commons sandbox, from
On 09/07/2012 22:12, Scott England-Sullivan wrote:
> Hello,
Hi Scott,
>
> I have developed a new component for the Apache Camel project written using
> pure Java JMS APIs (the current component is a Spring JMS wrapper). There
> have been requests made to make the API pulled out of the Camel com
Hello,
I have developed a new component for the Apache Camel project written using
pure Java JMS APIs (the current component is a Spring JMS wrapper). There
have been requests made to make the API pulled out of the Camel component
and to place them in a commons project for use by other projects (
Hi,
2012/7/9 Sébastien Brisard :
> HI,
>
> 2012/7/9 Sébastien Brisard :
>> Hello,
>>
>> 2012/7/9 Luc Maisonobe :
>>> On 09/07/2012 07:08, Sébastien Brisard wrote:
2012/7/9 Gilles Sadowski :
> On Sat, Jul 07, 2012 at 01:49:25PM +0200, Sébastien Brisard wrote:
>> Hello,
>> most exis
Hi,
>
> In fact, changing the return type does break binary compatibility (binary
> compatibility is different from source compatibility), since the return
> type of a method is part of is java signature.
> This means that if someone would want to use the new jar (with changed
> return type) as a
In fact, changing the return type does break binary compatibility (binary
compatibility is different from source compatibility), since the return
type of a method is part of is java signature.
This means that if someone would want to use the new jar (with changed
return type) as a drop-in replaceme
Hi Sebastien,
have a look at:
http://wiki.eclipse.org/Evolving_Java-based_APIs
http://wiki.eclipse.org/Evolving_Java-based_APIs_2
http://wiki.eclipse.org/Evolving_Java-based_APIs_3
In section Evolving API classes - API methods and constructors it says:
Change result type (including void) -
All,
in Commons-Math, class RealVector has a method unitize() which divides
each component of this by the norm. The vector is changed in place.
The current signature of this method is
public void unitize()
Most methods in class RealVector implement a fluent API. I would like
unitize() to follow th
13 matches
Mail list logo
