Re: [beanutils] release 1.9.3?

Go for it! dbrosIus schrieb am Di., 31. Mai 2016 um 23:35: > +1 > > Original message > From: Gary Gregory > Date: 05/31/2016 5:31 PM (GMT-05:00) > To: Commons Developers List > Subject: [beanutils]

Re: BCEL release?

Hi Olivier, Can you validate what is in trunk? That would help. It seems like there are clean ups and unfinished business since this is a major release. (See the deprecated org.apache.commons.bcel6.generic.InstructionConstants email thread I just started) Can you go through JIRA and help out

[bcel] Deprecated InstructionConstants

The interface org.apache.commons.bcel6.generic.InstructionConstants is deprecated in favor of a class. It seems OK to delete it since bcel6 is a major new release. Check? Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition

BCEL release?

Hi, Last release is from 2006. Fixes for java 8 are here for a while. Any ETA on releasing BCEL one day? Regards -- Olivier Lamy http://twitter.com/olamy | http://linkedin.com/in/olamy

RE: US Export classification & ECCN registration for encryption in commons?

Thank Stian for your review! >We also need a second for the (future) source/binary distributions >with ControlledSource href=https://www.apache.org/dist/commons/crypto/ - you >would need to duplicate the OpenSSL and JavaSE for that. >See other examples in the XML file. Thank you for pointing

[ANNOUNCEMENT] Apache Commons CSV 1.4

The Apache Commons team is pleased to announce the release of Apache Commons CSV 1.4. The Apache Commons CSV library provides a simple interface for reading and writing CSV files of various types. The main changes are the addition of a few APIs to make low-GC use-cases possible. Details of all

RE: [beanutils] release 1.9.3?

+1 Original message From: Gary Gregory Date: 05/31/2016 5:31 PM (GMT-05:00) To: Commons Developers List Subject: [beanutils] release 1.9.3? While there is not much new for 1.9.3, just two fixes, I would not mind pushing

[beanutils] release 1.9.3?

While there is not much new for 1.9.3, just two fixes, I would not mind pushing out a release, just to get the refreshed dependency on Commons Collection out since there has been noise about it related to security. Thoughts? Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java

Re: [math] Repository Policy

To reduce complexity and confusion, I would generally hope for "master" to be where development happens, rather than an additional "develop" - as that means we now have three levels of "releases" to deal with: * tagged/voted/published releases * a supposedly stable "master" that is somewhere

Re: [math] Repository Policy (was: Reverting changes on "master" as per Commons Math policy)

On Tue, May 31, 2016 at 5:43 PM, Rob Tompkins wrote: > On May 31, 2016, at 10:21 AM, Matt Sicker wrote: > > > > Why not just rename master to something like stable, then rename develop > to > > master? Less confusing to people who don't know about git-flow.

Re: [math] Repository Policy

Most servers allow you to specify a  default branch so that when you clone a repository you are on that branch.  I'm used to that from github, and didn't think twice about it,  which caused the last problem.  If this is possible here,  it would probably fix most cases.  Original

Re: [math] Repository Policy (was: Reverting changes on "master" as per Commons Math policy)

On May 31, 2016, at 10:21 AM, Matt Sicker wrote: > > Why not just rename master to something like stable, then rename develop to > master? Less confusing to people who don't know about git-flow. Generally when I think about an arbitrary github project I would think that the

Re: [Math] MATH-1371: Provide accelerated kmeans++ implementation

On Tue, May 31, 2016 at 4:45 PM, Gilles wrote: > Sorry, hit wrong key... > > On Tue, 31 May 2016 15:41:21 +0200, Gilles wrote: > >> On Tue, 31 May 2016 15:28:54 +0300, Artem Barger wrote: >> >>> Hi, >>> >>> Just finished the updated of the sources to address all

Re: [math] Repository Policy (was: Reverting changes on "master" as per Commons Math policy)

Why not just rename master to something like stable, then rename develop to master? Less confusing to people who don't know about git-flow. On 31 May 2016 at 03:58, Gilles wrote: > On Tue, 31 May 2016 09:34:25 +0200, Emmanuel Bourg wrote: > >> Le 31/05/2016 à

Re: [Math] MATH-1371: Provide accelerated kmeans++ implementation

Sorry, hit wrong key... On Tue, 31 May 2016 15:41:21 +0200, Gilles wrote: On Tue, 31 May 2016 15:28:54 +0300, Artem Barger wrote: Hi, Just finished the updated of the sources to address all comments from MATH-1371, attached updated sources. BTW, tried to commit feature branch directly to

Re: [Math] MATH-1371: Provide accelerated kmeans++ implementation

On Tue, 31 May 2016 15:28:54 +0300, Artem Barger wrote: Hi, Just finished the updated of the sources to address all comments from MATH-1371, attached updated sources. BTW, tried to commit feature branch directly to the remote, looks like I need a user or write access in order to being able

Re: [math] Repository Policy

On Tue, 31 May 2016 13:22:10 +0200, Emmanuel Bourg wrote: Le 31/05/2016 à 12:41, Gilles a écrit : Are you positive that people will not continue updating "master"? Well that depends on the modification pushed: - for trivial changes like updating the version of a maven plugin there is no

[Math] kmeans++: decouple EM LLoyd's iterations and initial seeding of clustering centers.

Hi, Current implementation of kmeans within CM framework, inherently uses algorithm published by Arthur, David, and Sergei Vassilvitskii. "k-means++: The advantages of careful seeding." *Proceedings of the eighteenth annual ACM-SIAM symposium on Discrete algorithms*. Society for Industrial and

Re: [math]: [MATH-1330] - KMeans clustering algorithm, doesn't support clustering of sparse input data.

Hi, I'm working on providing a solution for MATH-1330 and facing several design related issues which I'd like to share, since I'd like my solution to fit with the project road map and integrity. So, I'm looking on Clusterable interface and looks like automatically impose the way internal

[Math] Is generic parameter T is really needed for KMeansPlusPlusClusterer.

Hi, I'm just wondering whenever generic parameter for class KMeansPlusPlusClusterer is really needed? I mean, I do understand the initial intent of declaring it and trying to provide generic solution, however in really after all current implementation heavily relies on T being actually a

Re: [Math] MATH-1371: Provide accelerated kmeans++ implementation

Hi, Just finished the updated of the sources to address all comments from MATH-1371, attached updated sources. BTW, tried to commit feature branch directly to the remote, looks like I need a user or write access in order to being able to do it. Best regards, Artem Barger.

Re: Proposed changes to Complex method nomenclature

On Tue, 31 May 2016 11:12:06 +0200, Eric Barnhill wrote: I propose some minor changes in Complex() methods nomenclature for 4.0 . These relate to the collection of methods abs(), getArgument(), getReal() and getImaginary() . Personally I switch frequently and freely between Cartesian and

Re: [math] Repository Policy

Le 31/05/2016 à 12:41, Gilles a écrit : > Are you positive that people will not continue updating "master"? Well that depends on the modification pushed: - for trivial changes like updating the version of a maven plugin there is no point creating a feature branch, it can be committed directly on

Re: US Export classification & ECCN registration for encryption in commons?

Thanks! Looks good. We also need a second for the (future) source/binary distributions with ControlledSource href=https://www.apache.org/dist/commons/crypto/ - you would need to duplicate the OpenSSL and JavaSE for that. See other examples in the XML file. In the second Version you can say

Re: [math] Repository Policy

On Tue, 31 May 2016 11:33:19 +0200, Emmanuel Bourg wrote: Le 31/05/2016 à 10:58, Gilles a écrit : It causes confusion indeed but not because it is confusing. Rather because of years of svn usage which git vows to change IIUC. It's confusing because it's unexpected. If you look at the GitHub

RE: US Export classification & ECCN registration for encryption in commons?

Thank Stian and Haifeng, I have updated the file at my cms workspace. If the change is okay for you, I will try to commit it to http://www.staging.apache.org/licenses/exports/ Index: trunk/content/licenses/exports/index.page/eccnmatrix.xml

Re: [math] Repository Policy

Le 31/05/2016 à 10:58, Gilles a écrit : > It causes confusion indeed but not because it is confusing. > Rather because of years of svn usage which git vows to change IIUC. It's confusing because it's unexpected. If you look at the GitHub projects the majority don't use this so called "git

Proposed changes to Complex method nomenclature

I propose some minor changes in Complex() methods nomenclature for 4.0 . These relate to the collection of methods abs(), getArgument(), getReal() and getImaginary() . Personally I switch frequently and freely between Cartesian and polar representations of complex numbers in my code. So to me it

Re: [math] Repository Policy (was: Reverting changes on "master" as per Commons Math policy)

On Tue, 31 May 2016 09:34:25 +0200, Emmanuel Bourg wrote: Le 31/05/2016 à 03:37, er...@apache.org a écrit : Repository: commons-math Updated Branches: refs/heads/master ffc1caada -> 598edc127 Reverting changes on "master" as per Commons Math policy. The corresponding changes have been

Re: [math] Repository Policy (was: Reverting changes on "master" as per Commons Math policy)

Le 31/05/2016 à 03:37, er...@apache.org a écrit : > Repository: commons-math > Updated Branches: > refs/heads/master ffc1caada -> 598edc127 > > > Reverting changes on "master" as per Commons Math policy. > > The corresponding changes have been ported into branch "develop". Hi all, The