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
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
fe
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
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
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 Al
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-M
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 p
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.
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
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 pa
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?
> >
>
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://common
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
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
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
>
>
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
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 o
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 ar
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, IllegalStat
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
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,
>
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 1
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 Varia
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://c
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/m
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
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 modula
27 matches
Mail list logo
