Re: [Pool] Toward version 2.12.0 and 3.0

With 3.0, we should IMO bump to Java 11 or 17. FWIW, the only reason I have Java 8 on my machines are Apache projects like this one. Gary On Mon, Jul 17, 2023, 19:32 Gary Gregory wrote: > Great, thanks for the update :-) > > Gary > > On Mon, Jul 17, 2023, 19:11 Phil Steitz wrote: > >> +1 >>

Re: [Pool] Toward version 2.12.0 and 3.0

Do we want to keep JMX support for 3.0? Just curious, Gary On Mon, Jul 17, 2023, 19:32 Gary Gregory wrote: > Great, thanks for the update :-) > > Gary > > On Mon, Jul 17, 2023, 19:11 Phil Steitz wrote: > >> +1 >> >> I am doing soak tests now on the 2,x branch code and with DBCP. >> >> Phil >>

Re: Move math algorithms from all projects to math libraries

Thanks Gilles. I checked NUMBERS-193 and i have an implementation of DD and i will put it in *.ext package (TBD) along with some tests. Do i have to look at Dfd.java or something, because these dfd classes in math legacy core have lots of hard-coded decimals in there. Do these need to be copied to

Re: Move math algorithms from all projects to math libraries

Le mar. 18 juil. 2023 à 00:38, Dimitrios Efthymiou a écrit : > > good to know. I also see > https://cwiki.apache.org/confluence/display/COMMONS/MathWishList > Is this page still valid. At the top: ---CUT--- Created by ASF Infrabot, last modified on Nov 01, 2013 ---CUT--- What do you think? This

Re: [Pool] Toward version 2.12.0 and 3.0

Great, thanks for the update :-) Gary On Mon, Jul 17, 2023, 19:11 Phil Steitz wrote: > +1 > > I am doing soak tests now on the 2,x branch code and with DBCP. > > Phil > > On Sun, Jul 16, 2023 at 8:19 PM Gary Gregory > wrote: > > > The master branch is now on 3.0 and we have a 2.x branch as

Re: [Pool] Toward version 2.12.0 and 3.0

+1 I am doing soak tests now on the 2,x branch code and with DBCP. Phil On Sun, Jul 16, 2023 at 8:19 PM Gary Gregory wrote: > The master branch is now on 3.0 and we have a 2.x branch as well. > > The next release will be 2.12.0 and then we can keep discussing how to > handle 3: exceptions and

Re: Is there a need for a commons-physics project?

The main issue with jscience is lack of maintenance. It was invented around the time of JSR 275 which was ultimately rejected. The newer "units of measurement" work is in JSR 363 and JSR 385, while the currency/money stuff is in JSR 354. Even the "units of measurement" work is a bit fragmented.

Re: Move math algorithms from all projects to math libraries

good to know. I also see https://cwiki.apache.org/confluence/display/COMMONS/MathWishList Is this page still valid. I mean, could I work on one of these, like Add further functionality for BigDecimal and BigInteger

Re: Move math algorithms from all projects to math libraries

OK. That is what I need to know. Thank you Gilles On Mon, 17 Jul 2023 at 23:22, Gilles Sadowski wrote: > Le lun. 17 juil. 2023 à 20:49, Dimitrios Efthymiou > a écrit : > > > > All i am saying is that if HBase has a class, say MathUtils and a method > > add(double... numbers) and its body has

Re: Move math algorithms from all projects to math libraries

Le lun. 17 juil. 2023 à 20:49, Dimitrios Efthymiou a écrit : > > All i am saying is that if HBase has a class, say MathUtils and a method > add(double... numbers) and its body has the math algorithm to do addition, > we can just replace the method body with a call to the appropriate math > class

Re: Move math algorithms from all projects to math libraries

All i am saying is that if HBase has a class, say MathUtils and a method add(double... numbers) and its body has the math algorithm to do addition, we can just replace the method body with a call to the appropriate math class that does addition. That's all i am saying. HBase, for example already

Re: Move NO algorithms from ANY projects to math libraries

Hello. Le lun. 17 juil. 2023 à 12:50, Elliotte Rusty Harold a écrit : > > There are a lot of proposals floating recently to churn the API. I'm > going to move a direct no on all of this. > > Mild improvements in consistency in no way justify any API breakage or > even deprecation. We routinely

Re: Move math algorithms from all projects to math libraries

Le lun. 17 juil. 2023 à 15:19, Dimitrios Efthymiou a écrit : > > I don't have specific functionality in mind. You mentioned ASF projects which, IIUC, you said depend on "Commons Math". So I asked: On which "Commons Math" utilities do they depend? [Last time I checked (I don't remember where

Re: Is there a need for a commons-physics project?

Hi. Le lun. 17 juil. 2023 à 18:21, Thomas a écrit : > > Maybe start small, with a universally usable prerequisite: > > something like commons-unit as an implementation of javax.measure. https://github.com/javolution/jscience

Re: Move NO algorithms from ANY projects to math libraries

No proxying please. Usually "moving" means deprecating and removing in the next major version or never. Other components can add whatever they best see fit regardless of whether something's been deprecated elsewhere or not. Gary On Mon, Jul 17, 2023, 12:49 Mike Drob wrote: > Can we move

Re: Move NO algorithms from ANY projects to math libraries

Nothing will change then. Agreed. If you have a class MathUtils and a method add(double... numbers) then keep it, but replace the body if the method with the call to commons-numbers, for example. That's what I mean On Mon, 17 Jul 2023, 14:31 Elliotte Rusty Harold, wrote: > On Mon, Jul 17, 2023

Re: Move NO algorithms from ANY projects to math libraries

Can we move implementations, have old definitions be thin proxies to the new locations, mark existing methods as deprecated, and document that future development happens somewhere else? On Mon, Jul 17, 2023 at 9:55 AM sebb wrote: > On Mon, 17 Jul 2023 at 14:31, Elliotte Rusty Harold > wrote: >

Re: Is there a need for a commons-physics project?

Maybe start small, with a universally usable prerequisite: something like commons-unit as an implementation of javax.measure. See: https://unitsofmeasurement.github.io/unit-api/site/apidocs/javax/measure/class-use/Unit.html | javax.measure unit-api 1.0 Even if not used for physics

Re: Is there a need for a commons-physics project?

Hello. Le lun. 17 juil. 2023 à 13:53, Gary Gregory a écrit : > > It might already exist in Apache Sedona. Thanks for the pointer. >From a 30 s look at the web site[1] it seems more GIS-oriented. [It might be worth comparing its features with "Commons Geometry".] Regards, Gilles [1]

Re: Move NO algorithms from ANY projects to math libraries

On Mon, 17 Jul 2023 at 14:31, Elliotte Rusty Harold wrote: > > On Mon, Jul 17, 2023 at 9:21 AM Dimitrios Efthymiou > wrote: > > > > hello. I never said to redesign APIs. I only said that we can > > move math algorithms from non-math projects, to the math projects > > > > No, don't do that. > >

Re: [VOTE] Release Apache Commons FileUpload 2.0.0-M1 based on RC1

+1 Signatures Check Out Builds, tests, sitte on Java8, Java11, and Java17 All reports look good, (nit) the coverage is a little low 50-65% Rat reports all clean Only other Nit is a “NeedsWork" in org.apache.commons.fileupload2.javax.JavaxHttpServletRequestFactory likely more important than the

Re: Improve vulnerability reporting

(dropping security@c.a.o to avoid cross-posting between private and public lists) On Sat, Jul 15, 2023 at 6:26 PM wrote: > as suggested in the comments on > https://issues.apache.org/jira/browse/IMAGING-354 I am now raising this > issue here instead. > Thanks for sharing your experience! >

Re: Move NO algorithms from ANY projects to math libraries

On Mon, Jul 17, 2023 at 9:21 AM Dimitrios Efthymiou wrote: > > hello. I never said to redesign APIs. I only said that we can > move math algorithms from non-math projects, to the math projects > No, don't do that. Method signatures must not change. Class names must not change. Package names

Re: Move NO algorithms from ANY projects to math libraries

hello. I never said to redesign APIs. I only said that we can move math algorithms from non-math projects, to the math projects On Mon, 17 Jul 2023 at 11:50, Elliotte Rusty Harold wrote: > There are a lot of proposals floating recently to churn the API. I'm > going to move a direct no on all of

Re: Move math algorithms from all projects to math libraries

I don't have specific functionality in mind. I just had an idea to do a search for dependencies on java.lang.Math or BigInteger or BigDecimal and if I find any, I would see if these dependencies exist because the project has its own custom math algorithms. If yes then, there you go. We have

Re: [VOTE] Release Apache Commons FileUpload 2.0.0-M1 based on RC1

+1 Thanks Gary! - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org

Re: Is there a need for a commons-physics project?

It might already exist in Apache Sedona. Gary On Mon, Jul 17, 2023 at 7:35 AM Gilles Sadowski wrote: > > Short answer: No. > > We have had the (failed, for various reasons[1]) "Commons Math" > experiment. No need to try another one with such a vague scope. > > Regards, > Gilles > > [1] Cf.

Re: Is there a need for a commons-physics project?

Short answer: No. We have had the (failed, for various reasons[1]) "Commons Math" experiment. No need to try another one with such a vague scope. Regards, Gilles [1] Cf. record of discussions in the ML archives. - To

Move NO algorithms from ANY projects to math libraries

There are a lot of proposals floating recently to churn the API. I'm going to move a direct no on all of this. Mild improvements in consistency in no way justify any API breakage or even deprecation. Every method and class that currently exists in any commons library should continue to exist

Re: Move math algorithms from all projects to math libraries

Le lun. 17 juil. 2023 à 02:34, Dimitrios Efthymiou a écrit : > > I didn't say to introduce a dependency on math. I said that libraries that > already depend on math, may have math algorithms implemented that we could > replace with a call to the appropriate commons math methods Sounds nice. If

Re: Move math algorithms from all projects to math libraries

Hi. Le lun. 17 juil. 2023 à 02:08, Gary Gregory a écrit : > > At one point, I had proposed to deprecate Commons Lang' math package in > favor of something else in Commons Math or elsewhere. Commons Lang would > NOT depend on Commons Math/Other, we would just deprecate with a forwarding > link. >

Re: commons-fileupload2-jakarta

Le lun. 17 juil. 2023 à 08:19, Martin Tzvetanov Grigorov < mgrigo...@apache.org> a écrit : > > > On 2023/07/15 14:04:54 Emmanuel Bourg wrote: > > On 12/07/2023 13:27, Martin Tzvetanov Grigorov wrote: > > > > > Last time when I tried to replace Commons Fileupload with pure Servlet > API I faced

Re: commons-fileupload2-jakarta

On 2023/07/15 14:04:54 Emmanuel Bourg wrote: > On 12/07/2023 13:27, Martin Tzvetanov Grigorov wrote: > > > Last time when I tried to replace Commons Fileupload with pure Servlet API > > I faced these issues: > > > > 1) The Servlet API does not provide hooks to follow the upload progress > >