Re: Proposal to introduce JUnit 5 in commons-numbers

(please make sure to CC me on replies) +1 on this. One thing I'd like for us to avoid a mess of different junit versions making it difficult to know which runner will be executing the class. It would be great if we did a complete conversion and not just introduced new syntax. I've actually done th

[VOTE] Release Apache Commons Configuration 2.5 based on RC1

To: dev@commons.apache.org Subject: [VOTE] Release Apache Commons Configuration 2.5 based on RC1 We have fixed quite a few bugs and added some significant enhancements since Apache Commons Configuration 2.4 was released, so I would like to release Apache Commons Configuration 2.5. Apache Commons

Re: [commons-compress] branch master updated: Capitalized the first word of the exception messages

Nice clean up :-) Gary On Thu, May 23, 2019, 09:00 wrote: > This is an automated email from the ASF dual-hosted git repository. > > ebourg pushed a commit to branch master > in repository https://gitbox.apache.org/repos/asf/commons-compress.git > > > The following commit(s) were added to refs/h

Re: [statistics] Pull request for GLSMultipleLinearRegression

Hi Elena, Thanks for this intriguing idea. As far as I ever knew IRLS requires a matrix. Can you provide me with a citation where I can read about this vector-based approach? Thanks, Eric On Thu, May 23, 2019, 06:44 Елена Картышева wrote: > Hello. > > I would like to propose a pull request im

Re: [geometry] release

Gilles, In regard to the roadmap, there has been steady progress but not much is visible yet from the GitHub or JIRA point of view, unfortunately. I'm currently working on the final items from the initial roadmap email I sent out, namely the ones related to the BSP tree and Region API cleanup (

Re: [geometry] release

On 5/23/2019 9:49 AM, Gilles Sadowski wrote: Hi. Le jeu. 23 mai 2019 à 15:37, Rob Tompkins a écrit : On May 23, 2019, at 7:25 AM, Gilles Sadowski wrote: Hi. Le mer. 22 mai 2019 à 14:07, Matt Juntunen a écrit : Hi Sven, Until we can roll out an actual release of numbers and geometry

RE: [statistics] Pull request for GLSMultipleLinearRegression

Hello, There is currently a transition from the commons-math-stat libraries to the new commons-statistics library. I am working on regression related design for my Google Summer of Code project. I am a new contributor and would love to work with more people who have used these tools extensively

Re: [GSoC] Thursday mentee meeting

Hello. Le mer. 22 mai 2019 à 20:51, Eric Barnhill a écrit : > > Let's have another mentee meeting Thursday morning, same time as the > previous two. I won't be in front of the keyboard at 5 PM UTC. Two potential contributors (Aleksander Ściborek and Ellen Kartysheva) posted (here, on the "dev"

Re: [geometry] release

Hi. Le jeu. 23 mai 2019 à 15:37, Rob Tompkins a écrit : > > > > > On May 23, 2019, at 7:25 AM, Gilles Sadowski wrote: > > > > Hi. > > > >> Le mer. 22 mai 2019 à 14:07, Matt Juntunen a > >> écrit : > >> > >> Hi Sven, > >> > >> Until we can roll out an actual release of numbers and geometry, > >

[statistics] Pull request for GLSMultipleLinearRegression

Hello. I would like to propose a pull request implementing an option to use variance vector instead of covariance matrix. It allows users to avoid unnecessary memory usage and excessive computation in case of uncorrelated but heteroscedastic errors thus making it possible to work with huge inpu

Re: [geometry] release

> On May 23, 2019, at 7:25 AM, Gilles Sadowski wrote: > > Hi. > >> Le mer. 22 mai 2019 à 14:07, Matt Juntunen a >> écrit : >> >> Hi Sven, >> >> Until we can roll out an actual release of numbers and geometry, > > Any update of the roadmap? :-) Do we have a reason to not release? -Rob

[statistics] Pull request for GLSMultipleLinearRegression

I would like to propose a pull request implementing an option to use variance vector instead of covariance matrix. It allows users to avoid unnecessary memory usage and excessive computation in case of uncorrelated but heteroscedastic errors thus making it possible to work with huge input matrices.

Re: [rng] binary compatibility with final modifier

On 23/05/2019 13:46, Gilles Sadowski wrote: Hello. Le jeu. 23 mai 2019 à 14:10, Alex Herbert a écrit : On 23/05/2019 12:53, sebb wrote: Are the classes supposed to be final? Or just the existing constructor(s)? The two package-private classes are definitely helper classes and should be fi

Re: [rng] binary compatibility with final modifier

Hello. Le jeu. 23 mai 2019 à 14:10, Alex Herbert a écrit : > > > On 23/05/2019 12:53, sebb wrote: > > Are the classes supposed to be final? > > Or just the existing constructor(s)? > > The two package-private classes are definitely helper classes and should > be final. > > The class with the clir

Re: [rng] binary compatibility with final modifier

On 23/05/2019 12:53, sebb wrote: Are the classes supposed to be final? Or just the existing constructor(s)? The two package-private classes are definitely helper classes and should be final. The class with the clirr issue (it is actually an info) only has static methods. So currently it i

Aw: Re: [geometry] release

Hi, > This could be an approach: > https://maven.apache.org/plugins/maven-shade-plugin/[https://maven.apache.org/plugins/maven-shade-plugin/] I started to think in a similar direction and finally got it with the assembly-plugin (jar-with-dependencies). And "mvn deploy:deploy-file ..." did the re

Re: [rng] binary compatibility with final modifier

Are the classes supposed to be final? Or just the existing constructor(s)? On Thu, 23 May 2019 at 12:51, Gilles Sadowski wrote: > > Hello. > > Le jeu. 23 mai 2019 à 13:43, Alex Herbert a écrit : > > > > [rng] has three classes with a private constructor that are not > > currently marked as final

Re: [rng] binary compatibility with final modifier

Hello. Le jeu. 23 mai 2019 à 13:43, Alex Herbert a écrit : > > [rng] has three classes with a private constructor that are not > currently marked as final. 1 is public and 2 are package private. > > If I mark them as final then clirr:check ignores the package private > ones and produces this warn

Re: [statistics] PMD

Hi. Le jeu. 23 mai 2019 à 13:33, Alex Herbert a écrit : > > Having just fixed [rng] for PMD I had a look at why it was fine in > statistics as some of the issues are present there. > > PMD in statistics is old. It uses rules that are deprecated. > > I have updated to a similar ruleset to [rng] an

[rng] binary compatibility with final modifier

[rng] has three classes with a private constructor that are not currently marked as final. 1 is public and 2 are package private. If I mark them as final then clirr:check ignores the package private ones and produces this warning for the public one: "Added final modifier to class, but class w

[statistics] PMD

Having just fixed [rng] for PMD I had a look at why it was fine in statistics as some of the issues are present there. PMD in statistics is old. It uses rules that are deprecated. I have updated to a similar ruleset to [rng] and fixed all the problems. See this PR [1]. One rule violation is

[beanutils2] CVE-2014-0114 Pull Request

Hey All!, First time contributor here. My company has a corporate goal to only use open source libraries with NO open Security CVE's marked as critical. BeanUtils has CVE-2014-0114 marked as critical so I opened a ticket: https://issues.apache.org/jira/browse/BEANUTILS-520 I submitted my first

Re: [geometry] release

Hi. Le mer. 22 mai 2019 à 14:07, Matt Juntunen a écrit : > > Hi Sven, > > Until we can roll out an actual release of numbers and geometry, Any update of the roadmap? :-) > I think your best bet is to fork commons-geometry and all of its SNAPSHOT > dependencies, change the groupIds and/or artif

Re: [rng] default maven goal

Hi. Le jeu. 23 mai 2019 à 11:49, Alex Herbert a écrit : > > The [rng] pom does not have a default goal. Here are the default goals > in the projects I currently have checked out: > > commons-codec/pom.xml:clean verify apache-rat:check > clirr:check javadoc:javadoc > > commons-collections/pom.

[rng] default maven goal

The [rng] pom does not have a default goal. Here are the default goals in the projects I currently have checked out: commons-codec/pom.xml:    clean verify apache-rat:check clirr:check javadoc:javadoc commons-collections/pom.xml:    clean verify apache-rat:check clirr:check javadoc:javadoc