Re: [Pool] Toward version 2.12.0 and 3.0
FWIW, the only reason I have JDK 8 on my machines is Apache. Gary On Wed, Jul 19, 2023, 18:15 Phil Steitz wrote: > Exactly. I think at major version cuts, we should drop support for JDKs > that are no longer supported [1]. Part of that is simply availability of > JDKs to test against and the implied commitment to do that testing and fix > bugs that may be JDK-specific. Part of it is to allow use of new language > features. We only have this opportunity once - when we start the new major > version - and IMO we should always take it. > > Phil > > [1] That is getting a little trickier now with LTS. > > On Wed, Jul 19, 2023 at 2:42 PM Gary Gregory > wrote: > > > The simplest way to bake in JPMS automatically is to build with the > > Moditect plugin and Java 11. > > > > There is also an expectation from new contributors that current > development > > does not happen on the dead and EOL Java 8. It will be nice to at least > > have the option to use new language features and APIs. > > > > This is a major release and the perfect and expected time to bump Java > > versions IMO. > > > > Gary > > > > > > On Wed, Jul 19, 2023, 17:21 Alex Herbert > wrote: > > > > > On Wed, 19 Jul 2023 at 19:38, Gary Gregory > > wrote: > > > > > > > > OK, that sounds good. > > > > > > > > Gary > > > > > > > > On Tue, Jul 18, 2023 at 5:50 PM Phil Steitz > > > wrote: > > > > > > > > > > I would say 17 for 3.0. > > > > > > > > > > Phil > > > > > > Are there aspects of Pool that require moving away from JDK 8? Such a > > > move would restrict downstream consumers of the library. > > > > > > Alex > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > >
Re: [Pool] Toward version 2.12.0 and 3.0
Exactly. I think at major version cuts, we should drop support for JDKs that are no longer supported [1]. Part of that is simply availability of JDKs to test against and the implied commitment to do that testing and fix bugs that may be JDK-specific. Part of it is to allow use of new language features. We only have this opportunity once - when we start the new major version - and IMO we should always take it. Phil [1] That is getting a little trickier now with LTS. On Wed, Jul 19, 2023 at 2:42 PM Gary Gregory wrote: > The simplest way to bake in JPMS automatically is to build with the > Moditect plugin and Java 11. > > There is also an expectation from new contributors that current development > does not happen on the dead and EOL Java 8. It will be nice to at least > have the option to use new language features and APIs. > > This is a major release and the perfect and expected time to bump Java > versions IMO. > > Gary > > > On Wed, Jul 19, 2023, 17:21 Alex Herbert wrote: > > > On Wed, 19 Jul 2023 at 19:38, Gary Gregory > wrote: > > > > > > OK, that sounds good. > > > > > > Gary > > > > > > On Tue, Jul 18, 2023 at 5:50 PM Phil Steitz > > wrote: > > > > > > > > I would say 17 for 3.0. > > > > > > > > Phil > > > > Are there aspects of Pool that require moving away from JDK 8? Such a > > move would restrict downstream consumers of the library. > > > > Alex > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > >
Re: [Pool] Toward version 2.12.0 and 3.0
The simplest way to bake in JPMS automatically is to build with the Moditect plugin and Java 11. There is also an expectation from new contributors that current development does not happen on the dead and EOL Java 8. It will be nice to at least have the option to use new language features and APIs. This is a major release and the perfect and expected time to bump Java versions IMO. Gary On Wed, Jul 19, 2023, 17:21 Alex Herbert wrote: > On Wed, 19 Jul 2023 at 19:38, Gary Gregory wrote: > > > > OK, that sounds good. > > > > Gary > > > > On Tue, Jul 18, 2023 at 5:50 PM Phil Steitz > wrote: > > > > > > I would say 17 for 3.0. > > > > > > Phil > > Are there aspects of Pool that require moving away from JDK 8? Such a > move would restrict downstream consumers of the library. > > Alex > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [Pool] Toward version 2.12.0 and 3.0
On Wed, 19 Jul 2023 at 19:38, Gary Gregory wrote: > > OK, that sounds good. > > Gary > > On Tue, Jul 18, 2023 at 5:50 PM Phil Steitz wrote: > > > > I would say 17 for 3.0. > > > > Phil Are there aspects of Pool that require moving away from JDK 8? Such a move would restrict downstream consumers of the library. Alex - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons FileUpload 2.0.0-M1 based on RC1
This VOTE passes with the following +1s: - Bruno Kinoshita, binding - Maxim Solodovnik, non-binding - Rob Tompkins, binding - Gary Gregory, binding Gary On Wed, Jul 19, 2023 at 3:47 PM Gary Gregory wrote: > > My +1. > > Gary > > On Sun, Jul 16, 2023 at 7:57 AM Gary Gregory wrote: > > > > Hi All, > > > > This is the first milestone release for 2.0.0 which splits FileUpload > > into a multi-module project to support the Jakarta and legacy javax > > namespaces, so I would like to release Apache Commons FileUpload > > 2.0.0-M1. > > > > The previous release was Apache Commons FileUpload 1.5 (javax only). > > > > Apache Commons FileUpload 2.0.0-M1 RC1 is available for review here: > > https://dist.apache.org/repos/dist/dev/commons/fileupload/2.0.0-M1-RC1 > > (svn revision 63007) > > > > The Git tag commons-fileupload-2.0.0-M1-RC1 commit for this RC is > > 2107cd3dbb58417ccf1afae055aac3d5f597a665 which you can browse here: > > > > https://gitbox.apache.org/repos/asf?p=commons-fileupload.git;a=commit;h=2107cd3dbb58417ccf1afae055aac3d5f597a665 > > You may checkout this tag using: > > git clone https://gitbox.apache.org/repos/asf/commons-fileupload.git > > --branch commons-fileupload-2.0.0-M1-RC1 > > commons-fileupload-2.0.0-M1-RC1 > > > > Maven artifacts are here: > > > > https://repository.apache.org/content/repositories/orgapachecommons-1645/org/apache/commons/commons-fileupload2/2.0.0-M1/ > > > > #Release SHA-512s > > #Sat Jul 15 19:37:24 EDT 2023 > > org.apache.commons_commons-fileupload2-distribution-2.0.0-M1.spdx.json=d6062b88aa2a958295a1552f0a1641bc22ccf708e1f868ca8faee822fe42c88bf44fe93ffed39af550c352bc10126d435a066ae7c6a678cb5c907d7837690a10 > > commons-fileupload2-distribution-2.0.0-M1-bom.xml=793b199ef275ad28d76c827c8d515be848ae110f4a579030f5a1ca48c6f5b1ec14948d7d5cd428ee5cdfaa0ca9f24f39d1d14b4463763b0063f3b7288079ab6d > > commons-fileupload2-distribution-2.0.0-M1-bom.json=457481013a00ec85a27c9b70267daca8c9ed20e768bbafaff2d334d2023520f3e4f3b9aad62976bc19051bd923303902a6ddfe0eade11819d25eb3ceff9ed87c > > commons-fileupload2-2.0.0-M1-src.zip=e6108527d5beb505a198bd4ecc619f9024fdb9fa9cb771001213fd9b470568bb0f2a0ba2ddff85e6f0a69768544def9a66b0997875c9a7aa7fdbfce6fa91404c > > commons-fileupload2-2.0.0-M1-bin.zip=84067861fca81db81450c7f419f8c5a0bc2232f36277ceaba3771ade80c34297c142d698823885a9d03b646b8edfc7e7866c6c4411580fe20f63cbc237840bd0 > > commons-fileupload2-2.0.0-M1-src.tar.gz=44d94a1f449051b82fbfe05782eb85df2299713ed359fbbfd5c9fab085782ad97fb60eb2ef5d05d545dd16682ade3f6ae5f34b87216f0a4e79bbcd7f6c1d7723 > > commons-fileupload2-2.0.0-M1-bin.tar.gz=f7727ffd2df00b04ee7960b681eea35a4a320e9e8677f8ed77ac9b5841d6ee59d5df049104e1cea6bea475b4518b2ee2f50ac0b6a92cb1e9e2b142d56869b078 > > > > I have tested this with 'mvn clean install' using: > > > > Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f) > > Maven home: /usr/local/Cellar/maven/3.9.3/libexec > > Java version: 11.0.19, vendor: Homebrew, runtime: > > /usr/local/Cellar/openjdk@11/11.0.19/libexec/openjdk.jdk/Contents/Home > > Default locale: en_US, platform encoding: UTF-8 > > OS name: "mac os x", version: "13.4.1", arch: "x86_64", family: "mac" > > Darwin gdg-mac-mini.local 22.5.0 Darwin Kernel Version 22.5.0: Thu Jun > > 8 22:22:22 PDT 2023; root:xnu-8796.121.3~7/RELEASE_X86_64 x86_64 > > > > Java 11 was used to build with the Java 8 release flag in order to get > > all the little JPMS turds in the right place. > > > > Details of changes since 1.5 are in the release notes: > > > > https://dist.apache.org/repos/dist/dev/commons/fileupload/2.0.0-M1-RC1/RELEASE-NOTES.txt > > > > https://dist.apache.org/repos/dist/dev/commons/fileupload/2.0.0-M1-RC1/site/changes-report.html > > > > Site: > > > > https://dist.apache.org/repos/dist/dev/commons/fileupload/2.0.0-M1-RC1/site/index.html > > (note some *relative* links are broken and the 2.0.0-M1 > > directories are not yet created - these will be OK once the site is > > deployed.) > > > > There is no binary compatibility report because this is a major > > release in a new Java namespace and new Maven coordinates. > > > > RAT Report: > > > > https://dist.apache.org/repos/dist/dev/commons/fileupload/2.0.0-M1-RC1/site/rat-report.html > > > > KEYS: > > https://downloads.apache.org/commons/KEYS > > > > Please review the release candidate and vote. > > This vote will close no sooner than 72 hours from now. > > > > [ ] +1 Release these artifacts > > [ ] +0 OK, but... > > [ ] -0 OK, but really should fix... > > [ ] -1 I oppose this release because... > > > > Thank you, > > > > Gary Gregory, > > Release Manager (using key 86fdc7e2a11262cb) > > > > For following is intended as a helper and refresher for reviewers. > > > > Validating a release candidate > > == > > > > These guidelines are NOT complete. > > > > Requirements: Git, Java, Maven. > > > > You can validate a release from a release candidate (RC) tag as follows. > > > >
Re: [VOTE] Release Apache Commons FileUpload 2.0.0-M1 based on RC1
My +1. Gary On Sun, Jul 16, 2023 at 7:57 AM Gary Gregory wrote: > > Hi All, > > This is the first milestone release for 2.0.0 which splits FileUpload > into a multi-module project to support the Jakarta and legacy javax > namespaces, so I would like to release Apache Commons FileUpload > 2.0.0-M1. > > The previous release was Apache Commons FileUpload 1.5 (javax only). > > Apache Commons FileUpload 2.0.0-M1 RC1 is available for review here: > https://dist.apache.org/repos/dist/dev/commons/fileupload/2.0.0-M1-RC1 > (svn revision 63007) > > The Git tag commons-fileupload-2.0.0-M1-RC1 commit for this RC is > 2107cd3dbb58417ccf1afae055aac3d5f597a665 which you can browse here: > > https://gitbox.apache.org/repos/asf?p=commons-fileupload.git;a=commit;h=2107cd3dbb58417ccf1afae055aac3d5f597a665 > You may checkout this tag using: > git clone https://gitbox.apache.org/repos/asf/commons-fileupload.git > --branch commons-fileupload-2.0.0-M1-RC1 > commons-fileupload-2.0.0-M1-RC1 > > Maven artifacts are here: > > https://repository.apache.org/content/repositories/orgapachecommons-1645/org/apache/commons/commons-fileupload2/2.0.0-M1/ > > #Release SHA-512s > #Sat Jul 15 19:37:24 EDT 2023 > org.apache.commons_commons-fileupload2-distribution-2.0.0-M1.spdx.json=d6062b88aa2a958295a1552f0a1641bc22ccf708e1f868ca8faee822fe42c88bf44fe93ffed39af550c352bc10126d435a066ae7c6a678cb5c907d7837690a10 > commons-fileupload2-distribution-2.0.0-M1-bom.xml=793b199ef275ad28d76c827c8d515be848ae110f4a579030f5a1ca48c6f5b1ec14948d7d5cd428ee5cdfaa0ca9f24f39d1d14b4463763b0063f3b7288079ab6d > commons-fileupload2-distribution-2.0.0-M1-bom.json=457481013a00ec85a27c9b70267daca8c9ed20e768bbafaff2d334d2023520f3e4f3b9aad62976bc19051bd923303902a6ddfe0eade11819d25eb3ceff9ed87c > commons-fileupload2-2.0.0-M1-src.zip=e6108527d5beb505a198bd4ecc619f9024fdb9fa9cb771001213fd9b470568bb0f2a0ba2ddff85e6f0a69768544def9a66b0997875c9a7aa7fdbfce6fa91404c > commons-fileupload2-2.0.0-M1-bin.zip=84067861fca81db81450c7f419f8c5a0bc2232f36277ceaba3771ade80c34297c142d698823885a9d03b646b8edfc7e7866c6c4411580fe20f63cbc237840bd0 > commons-fileupload2-2.0.0-M1-src.tar.gz=44d94a1f449051b82fbfe05782eb85df2299713ed359fbbfd5c9fab085782ad97fb60eb2ef5d05d545dd16682ade3f6ae5f34b87216f0a4e79bbcd7f6c1d7723 > commons-fileupload2-2.0.0-M1-bin.tar.gz=f7727ffd2df00b04ee7960b681eea35a4a320e9e8677f8ed77ac9b5841d6ee59d5df049104e1cea6bea475b4518b2ee2f50ac0b6a92cb1e9e2b142d56869b078 > > I have tested this with 'mvn clean install' using: > > Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f) > Maven home: /usr/local/Cellar/maven/3.9.3/libexec > Java version: 11.0.19, vendor: Homebrew, runtime: > /usr/local/Cellar/openjdk@11/11.0.19/libexec/openjdk.jdk/Contents/Home > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x", version: "13.4.1", arch: "x86_64", family: "mac" > Darwin gdg-mac-mini.local 22.5.0 Darwin Kernel Version 22.5.0: Thu Jun > 8 22:22:22 PDT 2023; root:xnu-8796.121.3~7/RELEASE_X86_64 x86_64 > > Java 11 was used to build with the Java 8 release flag in order to get > all the little JPMS turds in the right place. > > Details of changes since 1.5 are in the release notes: > > https://dist.apache.org/repos/dist/dev/commons/fileupload/2.0.0-M1-RC1/RELEASE-NOTES.txt > > https://dist.apache.org/repos/dist/dev/commons/fileupload/2.0.0-M1-RC1/site/changes-report.html > > Site: > > https://dist.apache.org/repos/dist/dev/commons/fileupload/2.0.0-M1-RC1/site/index.html > (note some *relative* links are broken and the 2.0.0-M1 > directories are not yet created - these will be OK once the site is > deployed.) > > There is no binary compatibility report because this is a major > release in a new Java namespace and new Maven coordinates. > > RAT Report: > > https://dist.apache.org/repos/dist/dev/commons/fileupload/2.0.0-M1-RC1/site/rat-report.html > > KEYS: > https://downloads.apache.org/commons/KEYS > > Please review the release candidate and vote. > This vote will close no sooner than 72 hours from now. > > [ ] +1 Release these artifacts > [ ] +0 OK, but... > [ ] -0 OK, but really should fix... > [ ] -1 I oppose this release because... > > Thank you, > > Gary Gregory, > Release Manager (using key 86fdc7e2a11262cb) > > For following is intended as a helper and refresher for reviewers. > > Validating a release candidate > == > > These guidelines are NOT complete. > > Requirements: Git, Java, Maven. > > You can validate a release from a release candidate (RC) tag as follows. > > 1a) Clone and checkout the RC tag > > git clone https://gitbox.apache.org/repos/asf/commons-fileupload.git > --branch commons-fileupload-2.0.0-M1-RC1 > commons-fileupload-2.0.0-M1-RC1 > cd commons-fileupload-2.0.0-M1-RC1 > > 1b) Download and unpack the source archive from: > > https://dist.apache.org/repos/dist/dev/commons/fileupload/2.0.0-M1-RC1/source > > 2) Check Apache licenses > > This step is not required if
Re: [Pool] Toward version 2.12.0 and 3.0
OK, that sounds good. Gary On Tue, Jul 18, 2023 at 5:50 PM Phil Steitz wrote: > > I would say 17 for 3.0. > > Phil > > On Mon, Jul 17, 2023 at 8:00 PM Gary Gregory wrote: > > > 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 > > >> > > >> 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 API changes. > > >> > > > >> > Gary > > >> > > > >> > > > >> > On Mon, Jul 3, 2023 at 2:01 PM Phil Steitz > > >> wrote: > > >> > > > > >> > > +1 > > >> > > > > >> > > Phil > > >> > > > > >> > > On Mon, Jul 3, 2023 at 9:41 AM Gary Gregory > > > > >> > wrote: > > >> > > > > >> > > > Hi all, > > >> > > > > > >> > > > This is a switch from the 2.12.0 vote mail thread in order to > > >> discuss > > >> > 3.0 > > >> > > > and 2.x releases. > > >> > > > > > >> > > > I propose we switch master to 3.0 and create a branch called 2.x > > >> based > > >> > and > > >> > > > an old commit and release 2.12.0 from there. > > >> > > > > > >> > > > Gary > > >> > > > > > >> > > > >> > - > > >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > >> > For additional commands, e-mail: dev-h...@commons.apache.org > > >> > > > >> > > > >> > > > > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [commons-io] question: file content merge sort and binary search
Hi. Le mar. 18 juil. 2023 à 19:06, ssz a écrit : > > [...] > > We use this library as a second-level cache when parsing CIMXML RDF, this > file-based cache contains triples, and also subject-type pairs (RDF nodes). > It is not csv. > Also, I'm thinking about RDF-Graph implementation backed by fs. This is where the discussion, about whether "Commons" is the right place, could start because... > > So, I think we can always find ways to use this functionality. > Placing it in some common place would save other developers time. ... placing it here implies that there will be people willing to stay around and maintain ... > Implementation of file-sorting and searching is not so simple as it sounds. ... this "not so simple" functionality. That's why we ask for use-cases: People who have a direct interest in maintaining the functionality are more likely to help fix it when the need arises. IOW, I'd expect the contributors of a major functionality of which they are the only known users to stay around in order to support it. Regards, Gilles > [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] JIRA ticket for modularisation of all 14 legacy packages
Le mer. 19 juil. 2023 à 17:48, Elliotte Rusty Harold a écrit : > > On Wed, Jul 19, 2023 at 11:38 AM Gilles Sadowski wrote: > > > I think that the page one would look for is this one: > >https://commons.apache.org/proper/commons-math/dependency-info.html > > It's fine to put it there, but even if it's correct it's still too > hard to find. The only way to get to that page is scroll about two > thirds of the way down a sidebar and click one of the four links that > mention "dependencies" that seems as likely to bring you to a list of > commons-math's own dependencies rather than how to add this project as > a dependency. I'm a Maven comitter who's spent way more time in the > depths of Maven Project website generation than 99.9% of Java > programmers and I still couldn't find this the first time I looked for > it. That's de facto evidence that this information is not easy to > find. You are quite right. [IIRC, trying to figure it out from "Maven Central" is even worse.] The "Commons" web site esthetics and ergonomy has never attracted much attention. [After years of a new one being potentially available[1], even the logo did not change (all of the "new" ones will become obsolete in a few months following the ASF rebranding effort).] > > This coordinates belong right up front on > https://commons.apache.org/proper/commons-math/index.html +1 Would you file a report on https://issues.apache.org/jira/projects/COMMONSSITE/ ? > > I am tempted to see about changing the title of that page in the > sidebar from "Dependency Information" to "Maven Coordinates". Those pages are providing dependency info not only for maven: The info is there for (each module too), see e.g. https://commons.apache.org/proper/commons-math/commons-math4-transform/dependency-info.html but it would be nice indeed that the BOM snippet appears prominently on https://commons-math4-transform/dependency-info.html > That > would help a little and it's likely commons-math is hardly the only > project that has this issue. > The web site template is shared by all components. One change will fix them all. ;-) Well, not really: First step is to agree to generate a BOM module like Alex created for "RNG", and that the "Overview" page links to it. That would imply that all projects must become "modular" even if just to have two modules (one "code" and one BOM)... That would be "good" (TM), IMHO. Regards, Gilles [1] https://issues.apache.org/jira/projects/COMMONSSITE/issues/COMMONSSITE-86 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] JIRA ticket for modularisation of all 14 legacy packages
On Wed, Jul 19, 2023 at 11:38 AM Gilles Sadowski wrote: > I think that the page one would look for is this one: >https://commons.apache.org/proper/commons-math/dependency-info.html It's fine to put it there, but even if it's correct it's still too hard to find. The only way to get to that page is scroll about two thirds of the way down a sidebar and click one of the four links that mention "dependencies" that seems as likely to bring you to a list of commons-math's own dependencies rather than how to add this project as a dependency. I'm a Maven comitter who's spent way more time in the depths of Maven Project website generation than 99.9% of Java programmers and I still couldn't find this the first time I looked for it. That's de facto evidence that this information is not easy to find. This coordinates belong right up front on https://commons.apache.org/proper/commons-math/index.html I am tempted to see about changing the title of that page in the sidebar from "Dependency Information" to "Maven Coordinates". That would help a little and it's likely commons-math is hardly the only project that has this issue. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] JIRA ticket for modularisation of all 14 legacy packages
Le mer. 19 juil. 2023 à 16:03, Elliotte Rusty Harold a écrit : > > On Wed, Jul 19, 2023 at 9:53 AM Gilles Sadowski wrote: > > > > org.apache.commons.math4 and org.apache.commons.math3 > > > > > > Although it's not easy to find, > > > > What do you mean? > > Is it something we can fix here? > > > > Probably. I did a google search and hunted around on the web pages at > https://commons.apache.org/proper/commons-math/ > > Nowhere did I find a clear statement that "To import commons-math to > a project use the coordinates org.apache.commons:commons-math3:3.6.1" > or anything like that. I just took another look and I see something > for 4.0 at https://commons.apache.org/proper/commons-math/summary.html > but that's not the first place someone would look, and that's only for > the parent project. Not should the main website be for an unreleased > version. > > I'd put this on both Overview pages and probably the Developer's Guide > page at https://commons.apache.org/proper/commons-math/ I think that the page one would look for is this one: https://commons.apache.org/proper/commons-math/dependency-info.html Unfortunately, the "auto-generating" script/template does not take modular maven projects into account. Rather than assuming a single artefact, the build should somehow generate a BOM that would transitively fetch all the modules. I think that Alex managed to do just that for "Commons RNG".[1] Regards, Gilles [1] https://commons.apache.org/proper/commons-rng/commons-rng-bom/index.html - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] JIRA ticket for modularisation of all 14 legacy packages
On Wed, Jul 19, 2023 at 9:53 AM Gilles Sadowski wrote: > > org.apache.commons.math4 and org.apache.commons.math3 > > > > Although it's not easy to find, > > What do you mean? > Is it something we can fix here? > Probably. I did a google search and hunted around on the web pages at https://commons.apache.org/proper/commons-math/ Nowhere did I find a clear statement that "To import commons-math to a project use the coordinates org.apache.commons:commons-math3:3.6.1" or anything like that. I just took another look and I see something for 4.0 at https://commons.apache.org/proper/commons-math/summary.html but that's not the first place someone would look, and that's only for the parent project. Not should the main website be for an unreleased version. I'd put this on both Overview pages and probably the Developer's Guide page at https://commons.apache.org/proper/commons-math/ -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] JIRA ticket for modularisation of all 14 legacy packages
Le mer. 19 juil. 2023 à 14:58, Elliotte Rusty Harold a écrit : > > Commons Math 4 and Commons Math 3 have different java packages: > > org.apache.commons.math4 and org.apache.commons.math3 > > Although it's not easy to find, What do you mean? Is it something we can fix here? > it does look like the Maven > coordinates have changed as well. > > so it's effectively a completely new release of a new project that > can coexist with the older project in a classpath. That shouldn't > cause any dependency problems. :-) Thanks, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] JIRA ticket for modularisation of all 14 legacy packages
Commons Math 4 and Commons Math 3 have different java packages: org.apache.commons.math4 and org.apache.commons.math3 Although it's not easy to find, it does look like the Maven coordinates have changed as well. so it's effectively a completely new release of a new project that can coexist with the older project in a classpath. That shouldn't cause any dependency problems. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] JIRA ticket for modularisation of all 14 legacy packages
Hi. Le mer. 19 juil. 2023 à 13:43, Elliotte Rusty Harold a écrit : > > Ok, don't do that unless it's new code in new packages. Otherwise > you're creating a dependency hell for existing clients. It is > extremely developer hostile. Pretty much all of https://jlbp.dev/ > applies but especially > > JLBP-5: Do not include a class in more than one classpath entry > JLBP-6: Rename artifacts and packages together I repeat that it has been "Commons policy" for over 15 years. If I missed something, please use concrete examples, based on the modules shipped with v4.0-beta1, so that we can fix it before the "non-beta" release. Thanks, Gilles > > Debugging the problems this will cause is difficult and painful, even > for someone well-versed in Maven dependency management. > > On Wed, Jul 19, 2023 at 11:37 AM Dimitrios Efthymiou > wrote: > > > > no. I mean creating maven modules inside commons-math, like > > the existing ones: > > commons-math-neuralnet > > commons-math-transform > > > > > [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] JIRA ticket for modularisation of all 14 legacy packages
Hello. Le mer. 19 juil. 2023 à 12:59, Dimitrios Efthymiou a écrit : > > thanks Gilles. > 1--I think I broke the build, because I did not include (correctly) > the dependency on clustering inside the root pom.xml. My local build > succeeds. I hope that the GitHub build succeeds, as well. It doesn't. > 2--As for the atomic refactoring and feature branch, well, > unless someone moves the Variance class (you said that someone > is doing it now) and the distance package and whatever other > dependencies exist within the ml.clustering package, > there can be no moving of the remaining clustering classes > to the new clustering module, right? Wrong. I made a suggestion on JIRA. > 3--I see that the commons-statistics project, for example, > has empty modules. I think the geometry project (I don't remember which one) > has some classes that are still in commons-math Which ones? > because the migration > is not complete. The migration was completed (it took almost two years) before releasing v1.0 of the [Geometry] component. > So, I thought that I coud do the same i.e. move > the clusteirng classes that do not depend on anything The "same" is doing what I suggested (cf. above). > 4--I don't know how to continue with the clustering modularisation > given all those dependencies. Maybe I shouldn't have started this, > because now I am stuck If the work would have only consisted in copying Java files from one directory to another... It would have been done already. Even for packages that didn't have any dependency (see e.g. the "commons-math-transform" module), the port involved looking at the API to make it more "modern" and/or user-friendly. The "clustering" case is more complicated because, in addition to the API changes and enhancements, there are (few) dependencies (to remove), and bugs (to fix). Please look at the JIRA reports. [One main issue is how to represent a point in (problem domain) space and cluster of those, and distance between them, ...] Regards, Gilles >> [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] JIRA ticket for modularisation of all 14 legacy packages
I see. I didn't suggest I would start creating modules here and there. I just wanted to know if there is a plan to, eventually, put all those legacy packages into their own projects like analysis, linear algebra, special functions, optimisation, etc. That's all. I am not gonna do it. But since on of my favourite things in programming is playing with legacy code and refactoring, I wanted to know if there is a plan for these things. I guess eventually, yes. On Wed, 19 Jul 2023 at 12:43, Elliotte Rusty Harold wrote: > Ok, don't do that unless it's new code in new packages. Otherwise > you're creating a dependency hell for existing clients. It is > extremely developer hostile. Pretty much all of https://jlbp.dev/ > applies but especially > > JLBP-5: Do not include a class in more than one classpath entry > JLBP-6: Rename artifacts and packages together > > Debugging the problems this will cause is difficult and painful, even > for someone well-versed in Maven dependency management. > > On Wed, Jul 19, 2023 at 11:37 AM Dimitrios Efthymiou > wrote: > > > > no. I mean creating maven modules inside commons-math, like > > the existing ones: > > commons-math-neuralnet > > commons-math-transform > > > > On Wed, 19 Jul 2023 at 12:29, Elliotte Rusty Harold > > wrote: > > > > > Could you be precise about what you mean by "modularisation"? It's a > > > very overloaded term. Do you mean Java 9 modules as defined by the > > > JPMS? > > > > > > On Wed, Jul 19, 2023 at 12:33 AM Dimitrios Efthymiou > > > wrote: > > > > > > > > Hello everyone. Is there, or gonna be, a dedicated ticket for the > > > > modularisation of all 14 packages commons-math-legacy has? I think > that > > > > some of them are easy to modularise like optimisation, special and > filter > > > > > > > > > > > > -- > > > Elliotte Rusty Harold > > > elh...@ibiblio.org > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > -- > Elliotte Rusty Harold > elh...@ibiblio.org > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [math] JIRA ticket for modularisation of all 14 legacy packages
Ok, don't do that unless it's new code in new packages. Otherwise you're creating a dependency hell for existing clients. It is extremely developer hostile. Pretty much all of https://jlbp.dev/ applies but especially JLBP-5: Do not include a class in more than one classpath entry JLBP-6: Rename artifacts and packages together Debugging the problems this will cause is difficult and painful, even for someone well-versed in Maven dependency management. On Wed, Jul 19, 2023 at 11:37 AM Dimitrios Efthymiou wrote: > > no. I mean creating maven modules inside commons-math, like > the existing ones: > commons-math-neuralnet > commons-math-transform > > On Wed, 19 Jul 2023 at 12:29, Elliotte Rusty Harold > wrote: > > > Could you be precise about what you mean by "modularisation"? It's a > > very overloaded term. Do you mean Java 9 modules as defined by the > > JPMS? > > > > On Wed, Jul 19, 2023 at 12:33 AM Dimitrios Efthymiou > > wrote: > > > > > > Hello everyone. Is there, or gonna be, a dedicated ticket for the > > > modularisation of all 14 packages commons-math-legacy has? I think that > > > some of them are easy to modularise like optimisation, special and filter > > > > > > > > -- > > Elliotte Rusty Harold > > elh...@ibiblio.org > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [pool] advertising unchecked exceptions
Sounds good. Gary On Tue, Jul 18, 2023, 18:54 Phil Steitz wrote: > I am going through now and comparing diffs of 2.11.1 and head of 2.x to > make sure that me and sed did not do anything wrong and I am seeing a bunch > of things like this: > > -void addObject() throws Exception, IllegalStateException, > -UnsupportedOperationException; > +void addObject() throws Exception; > > Where the new version is the 2.x code. I am inclined to leave as is, maybe > adding comments in some places indicating when the unchecked exceptions > might be thrown. Any objections? > > Phil >
Re: [math] JIRA ticket for modularisation of all 14 legacy packages
no. I mean creating maven modules inside commons-math, like the existing ones: commons-math-neuralnet commons-math-transform On Wed, 19 Jul 2023 at 12:29, Elliotte Rusty Harold wrote: > Could you be precise about what you mean by "modularisation"? It's a > very overloaded term. Do you mean Java 9 modules as defined by the > JPMS? > > On Wed, Jul 19, 2023 at 12:33 AM Dimitrios Efthymiou > wrote: > > > > Hello everyone. Is there, or gonna be, a dedicated ticket for the > > modularisation of all 14 packages commons-math-legacy has? I think that > > some of them are easy to modularise like optimisation, special and filter > > > > -- > Elliotte Rusty Harold > elh...@ibiblio.org > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [pool] advertising unchecked exceptions
On Tue, Jul 18, 2023 at 10:54 PM Phil Steitz wrote: > > I am going through now and comparing diffs of 2.11.1 and head of 2.x to > make sure that me and sed did not do anything wrong and I am seeing a bunch > of things like this: > > -void addObject() throws Exception, IllegalStateException, > -UnsupportedOperationException; > +void addObject() throws Exception; > > Where the new version is the 2.x code. I am inclined to leave as is, maybe > adding comments in some places indicating when the unchecked exceptions > might be thrown. Any objections? > That sounds good. This is generally best practice for runtime exceptions. Don't include them in throws clauses but do include @throws Javadoc for each one. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] JIRA ticket for modularisation of all 14 legacy packages
Could you be precise about what you mean by "modularisation"? It's a very overloaded term. Do you mean Java 9 modules as defined by the JPMS? On Wed, Jul 19, 2023 at 12:33 AM Dimitrios Efthymiou wrote: > > Hello everyone. Is there, or gonna be, a dedicated ticket for the > modularisation of all 14 packages commons-math-legacy has? I think that > some of them are easy to modularise like optimisation, special and filter -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] JIRA ticket for modularisation of all 14 legacy packages
thanks Gilles. 1--I think I broke the build, because I did not include (correctly) the dependency on clustering inside the root pom.xml. My local build succeeds. I hope that the GitHub build succeeds, as well. 2--As for the atomic refactoring and feature branch, well, unless someone moves the Variance class (you said that someone is doing it now) and the distance package and whatever other dependencies exist within the ml.clustering package, there can be no moving of the remaining clustering classes to the new clustering module, right? 3--I see that the commons-statistics project, for example, has empty modules. I think the geometry project (I don't remember which one) has some classes that are still in commons-math, because the migration is not complete. So, I thought that I coud do the same i.e. move the clusteirng classes that do not depend on anything 4--I don't know how to continue with the clustering modularisation given all those dependencies. Maybe I shouldn't have started this, because now I am stuck On Wed, 19 Jul 2023 at 11:36, Gilles Sadowski wrote: > Hello. > > Le mer. 19 juil. 2023 à 11:21, Dimitrios Efthymiou > a écrit : > > > > I saw 1575, but I didn't see subtasks for all 14 packages. > > Is there a plan to modularise all 14 packages? > > Obviously, it would be good to achieve that, as pointed out > in the release notes of version 4.0-beta1: > https://commons.apache.org/proper/commons-math/changes-report.html > > But there is no "plan", like an ordered list of instructions to > follow from start to end. > The general task is "refactoring". > > > As for the dependencies on core, linear, analysis, well, > > from what I know, the way to modularise a codebase that > > was not designed to be modular, is to start moving classes > > that do not depend on legacy ones, 1-by-1, > > And break the build like it is currently the case with the > "clustering" refactoring? > > > slowly. > > As noted on JIRA[1], the move of an existing functionality into > its own (maven) module should be "atomic" on the "master" > branch. When the refactoring (started on a developer's local > machine) is sufficiently advanced, we can create a feature > branch so that several developers can more easily collaborate. > > > For classes that depend on legacy ones, then we can create > > new analysis and linear modules, create interfaces in them > > that have the methods our new modularised classes need, > > have the legacy classes in analysis and linear implement > > those interfaces, have the legacy module depend on the new > > analysis and linear modules (since they have the new interfaces), > > have the new optimisation module depend on the new > > analysis and linear modules and gradually you can move implementation > > code from the legacy to the new modules. The dependencies > > will be from legacy to the new modules and not the other way > > around. So the process I would try is: > > 1--create module commons-math-optimisation > > 2--create module commons-math-analysis > > 3--create module commons-math-linear-algebra > > 4--see on which analysis classes does optimisation depends? > > 5--see no which specific methods does optimisation depends? > > 6--create interfaces in commons-math-analysis for those classes and their > > methods that optimisation needs > > 7--have the analysis classes implement their respective interfaces from > > commons-math-analysis (maintaining the API) > > 8--have commons-math-legacy depend on commons-math-analysis and > > commons-math-linear-algebra > > 9--use these interfaces from within commons-math-optimisation > > 10-gradual move of methods and classes from commons-math-legacy to > > commons-math-optimisation, commons-math-analysis, > > commons-math-linear-algebra > > Sure! :-} > The devil is in the details... > > One crucial task is to have a way to (optionally) call external > implementations of linear algebra algorithms and data-structures. > I've no idea whether it's possible to adapt all the functionality to a > new design based only on interfaces (and not loose performance). > Unless we can really switch between alternative implementations > this is a lot of work with literally no gain. > Another possibility (also mentioned in [1]) is to isolate the needed > utilities in a "private" toolbox. [However, I'd be *very* reluctant if it > entails copying several hundred or thousand lines.] > > Regards, > Gilles > > [1] > https://issues.apache.org/jira/browse/MATH-1579?focusedCommentId=17744504=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17744504 > > > > > On Wed, 19 Jul 2023 at 09:49, Gilles Sadowski > wrote: > > > > > Hello. > > > > > > Le mer. 19 juil. 2023 à 02:33, Dimitrios Efthymiou > > > a écrit : > > > > > > > > Hello everyone. Is there, or gonna be, a dedicated ticket for the > > > > modularisation of all 14 packages commons-math-legacy has? > > > > > > https://issues.apache.org/jira/browse/MATH-1575 > > > > > > > I think that > > > > some of
Re: [math] JIRA ticket for modularisation of all 14 legacy packages
Hello. Le mer. 19 juil. 2023 à 11:21, Dimitrios Efthymiou a écrit : > > I saw 1575, but I didn't see subtasks for all 14 packages. > Is there a plan to modularise all 14 packages? Obviously, it would be good to achieve that, as pointed out in the release notes of version 4.0-beta1: https://commons.apache.org/proper/commons-math/changes-report.html But there is no "plan", like an ordered list of instructions to follow from start to end. The general task is "refactoring". > As for the dependencies on core, linear, analysis, well, > from what I know, the way to modularise a codebase that > was not designed to be modular, is to start moving classes > that do not depend on legacy ones, 1-by-1, And break the build like it is currently the case with the "clustering" refactoring? > slowly. As noted on JIRA[1], the move of an existing functionality into its own (maven) module should be "atomic" on the "master" branch. When the refactoring (started on a developer's local machine) is sufficiently advanced, we can create a feature branch so that several developers can more easily collaborate. > For classes that depend on legacy ones, then we can create > new analysis and linear modules, create interfaces in them > that have the methods our new modularised classes need, > have the legacy classes in analysis and linear implement > those interfaces, have the legacy module depend on the new > analysis and linear modules (since they have the new interfaces), > have the new optimisation module depend on the new > analysis and linear modules and gradually you can move implementation > code from the legacy to the new modules. The dependencies > will be from legacy to the new modules and not the other way > around. So the process I would try is: > 1--create module commons-math-optimisation > 2--create module commons-math-analysis > 3--create module commons-math-linear-algebra > 4--see on which analysis classes does optimisation depends? > 5--see no which specific methods does optimisation depends? > 6--create interfaces in commons-math-analysis for those classes and their > methods that optimisation needs > 7--have the analysis classes implement their respective interfaces from > commons-math-analysis (maintaining the API) > 8--have commons-math-legacy depend on commons-math-analysis and > commons-math-linear-algebra > 9--use these interfaces from within commons-math-optimisation > 10-gradual move of methods and classes from commons-math-legacy to > commons-math-optimisation, commons-math-analysis, > commons-math-linear-algebra Sure! :-} The devil is in the details... One crucial task is to have a way to (optionally) call external implementations of linear algebra algorithms and data-structures. I've no idea whether it's possible to adapt all the functionality to a new design based only on interfaces (and not loose performance). Unless we can really switch between alternative implementations this is a lot of work with literally no gain. Another possibility (also mentioned in [1]) is to isolate the needed utilities in a "private" toolbox. [However, I'd be *very* reluctant if it entails copying several hundred or thousand lines.] Regards, Gilles [1] https://issues.apache.org/jira/browse/MATH-1579?focusedCommentId=17744504=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17744504 > > On Wed, 19 Jul 2023 at 09:49, Gilles Sadowski wrote: > > > Hello. > > > > Le mer. 19 juil. 2023 à 02:33, Dimitrios Efthymiou > > a écrit : > > > > > > Hello everyone. Is there, or gonna be, a dedicated ticket for the > > > modularisation of all 14 packages commons-math-legacy has? > > > > https://issues.apache.org/jira/browse/MATH-1575 > > > > > I think that > > > some of them are easy to modularise like optimisation, > > > > When I list the dependencies towards other packages in "legacy", > > I see > > o.a.c.math4.legacy.core > > o.a.c.math4.legacy.linear > > o.a.c.math4.legacy.analysis > > > > How do you suggest to handle it? > > > > > special > > > > Here, there is only one class, but it should be analysed to > > suggest a better API (and maybe improve performance). > > There is also the question of whether to provide this and other > > special functions with extended precision[1] (and maybe move > > them to [Numbers]; like the gamma family of functions). > > > > > and filter > > > > When I list the dependencies towards other packages in "legacy", > > I see > > o.a.c.math4.legacy.linear > > > > Regards, > > Gilles > > > > > > [1] See section 7.4 in D. Bailey's documentation: > > https://www.davidhbailey.com/dhbpapers/mpfun2020.pdf - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [commons-io] question: file content merge sort and binary search
I added some additional details to README.md
Please let me know if I can add something for more understanding.
On Tue, Jul 18, 2023 at 7:25 PM Gilles Sadowski
wrote:
> Hello.
>
> Le mar. 18 juil. 2023 à 17:35, ssz a écrit :
> >
> > here
> https://github.com/sszuev/textfile-utils-examples/tree/master/src/test
>
> Yes, this shows the API and its usage, but I was also wondering
> about actual uses. What kind of applications would need to call
> this functionality from Java? What does your implementation bring
> which a user cannot do with "sort"?[1]
>
> Best regards,
> Gilles
>
> [1] https://en.wikipedia.org/wiki/Sort_(Unix)
>
> >
> > On Tue, Jul 18, 2023 at 12:03 PM Gilles Sadowski
> > wrote:
> >
> > > Hello.
> > >
> > > Le mar. 18 juil. 2023 à 10:50, ssz a écrit :
> > > >
> > > > Hello there
> > > >
> > > > I see this issue on hold.
> > > > So far, no one else has an opinion on this issue.
> > >
> > > Maybe "Commons Text"?
> > > It would help to see use-cases and API examples (in Java).
> > >
> > > Regards,
> > > Gilles
> > >
> > > > I'm going to unsubscribe from this list for a while.
> > > > Please email me directly in case of a positive final decision.
> > > >
> > > > sss.zuev {at} gmail / com
> > > >
> > > >>> [...]
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
Re: [math] JIRA ticket for modularisation of all 14 legacy packages
I saw 1575, but I didn't see subtasks for all 14 packages. Is there a plan to modularise all 14 packages? As for the dependencies on core, linear, analysis, well, from what I know, the way to modularise a codebase that was not designed to be modular, is to start moving classes that do not depend on legacy ones, 1-by-1, slowly. For classes that depend on legacy ones, then we can create new analysis and linear modules, create interfaces in them that have the methods our new modularised classes need, have the legacy classes in analysis and linear implement those interfaces, have the legacy module depend on the new analysis and linear modules (since they have the new interfaces), have the new optimisation module depend on the new analysis and linear modules and gradually you can move implementation code from the legacy to the new modules. The dependencies will be from legacy to the new modules and not the other way around. So the process I would try is: 1--create module commons-math-optimisation 2--create module commons-math-analysis 3--create module commons-math-linear-algebra 4--see on which analysis classes does optimisation depends? 5--see no which specific methods does optimisation depends? 6--create interfaces in commons-math-analysis for those classes and their methods that optimisation needs 7--have the analysis classes implement their respective interfaces from commons-math-analysis (maintaining the API) 8--have commons-math-legacy depend on commons-math-analysis and commons-math-linear-algebra 9--use these interfaces from within commons-math-optimisation 10-gradual move of methods and classes from commons-math-legacy to commons-math-optimisation, commons-math-analysis, commons-math-linear-algebra On Wed, 19 Jul 2023 at 09:49, Gilles Sadowski wrote: > Hello. > > Le mer. 19 juil. 2023 à 02:33, Dimitrios Efthymiou > a écrit : > > > > Hello everyone. Is there, or gonna be, a dedicated ticket for the > > modularisation of all 14 packages commons-math-legacy has? > > https://issues.apache.org/jira/browse/MATH-1575 > > > I think that > > some of them are easy to modularise like optimisation, > > When I list the dependencies towards other packages in "legacy", > I see > o.a.c.math4.legacy.core > o.a.c.math4.legacy.linear > o.a.c.math4.legacy.analysis > > How do you suggest to handle it? > > > special > > Here, there is only one class, but it should be analysed to > suggest a better API (and maybe improve performance). > There is also the question of whether to provide this and other > special functions with extended precision[1] (and maybe move > them to [Numbers]; like the gamma family of functions). > > > and filter > > When I list the dependencies towards other packages in "legacy", > I see > o.a.c.math4.legacy.linear > > Regards, > Gilles > > > [1] See section 7.4 in D. Bailey's documentation: > https://www.davidhbailey.com/dhbpapers/mpfun2020.pdf > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [math] JIRA ticket for modularisation of all 14 legacy packages
Hello. Le mer. 19 juil. 2023 à 02:33, Dimitrios Efthymiou a écrit : > > Hello everyone. Is there, or gonna be, a dedicated ticket for the > modularisation of all 14 packages commons-math-legacy has? https://issues.apache.org/jira/browse/MATH-1575 > I think that > some of them are easy to modularise like optimisation, When I list the dependencies towards other packages in "legacy", I see o.a.c.math4.legacy.core o.a.c.math4.legacy.linear o.a.c.math4.legacy.analysis How do you suggest to handle it? > special Here, there is only one class, but it should be analysed to suggest a better API (and maybe improve performance). There is also the question of whether to provide this and other special functions with extended precision[1] (and maybe move them to [Numbers]; like the gamma family of functions). > and filter When I list the dependencies towards other packages in "legacy", I see o.a.c.math4.legacy.linear Regards, Gilles [1] See section 7.4 in D. Bailey's documentation: https://www.davidhbailey.com/dhbpapers/mpfun2020.pdf - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
